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PREFACE 


The Flight Design System-1 (FDS-1) is a pilot project to evaluate current con- 
cepts, and to determine the hardware/ software capability that will be required 
for the operational era to support Shuttle flight planning. This software sys- 
tem is being implemented on a Hewlett-Paokard 21MX (HP21MX) computer combined 
with a Daconlcs documentation system, and will provide terminal- based 
interactive flight planning oapablllty. 

The System Design Document (SDD) for FDS-1 is the specification for, and descrip- 
tion of, this hardware/software (HW/SW) facility. The SDD is logically 
organized into 10 published volumes. This organization is presented in the 
accompanying table. The material in the early volumes is primarily presented 
from the user's point of view, whereas the latter material is software-developer 
oriented. The SDD will be published by volumes over a period of time, and vari- 
ous volumes will be updated and republished during the development of FDS-1. 
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1.0 laiEPJCUfiXIflH. 

A prime objeobivo of bhe Flight Design System (PDS) is to increase the prcduo- 
bivity of the flight planning engineers sufficiently to permit support of the 
high flight rate of bhe Shuttle operations era within present staffing levels. 
One of bhe features of the FDS design that is intended to *gnJ fioantly reduce 
the man-hours required per flight design cycle is rhe ability to produce the 
major flight design documents with little or no manual typing. This volume 
desoribes the set of applioabion software that provides this capability. 

The documentation support software is divided into two separately executable 
processors, However, since both processors support the same overall function, 
and moat of bhe software contained in one is also contained in the other, both 
are collectively described in this seotion. 
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2.0 jaESFJKE. 

Tho basic oonoepb of semlautomabect documentation for the FDS consists of 
combining prestruotured document formats with flight-dependent data and 
fonnattlr^ the result In a form suitable for printing as a complete document. 

The prestruotured dooument furmats are created and maintained on the Daconlos 
word processing system. The flight-dependent data anii produced by the PDS and 
are stored in named data elements on the HP21MX computer, The two hardware sys- 
tems are oonneobed by a oore-to-ooro data channel over whloh the empty dooument 
formats are transmitted to the HP21MX, the combined formats and data are 
returned to the Daoonios, The oombir.ing of data with formats is performed by 
the documentation processor (DOC ) , a set of applloatlon software that resides on 
the HP21MX. 

A document is constructed from a set of separately complete portions called 
segments. Bach segment, Identified by a document and segment Identifier, is 
defined by a preformatbed fbrm and an asLiOolated table that defines each data el- 
ement to be Inserted into reserved spaces In the form. This table, called the 
do'umenb descriptor table (DDT), defines the order in whloh data are to be 
inserted into the form, and specifics the format In the segment for each data el- 
ement, Figure 2-1 shows a sample fct'u, figure 2-2 describes the contents of a 
DDT, and figure 2-3 shows the sample DDT that corresponds to the sample form in 
figure 2-1 , 

A second table is required to establish ;he linkages between the parameters 
defined in the DDT and the named data elements in the active work area (AWA) of 
the FDS, This table is called the linkage table (LT) and is described in figure 
2-H. A sample LT is shown in figure 2-r. 

A separate program exists that produces and modifies LT's. This program, called 
the Linkage Table Build Program (LTBLD), is used to construct default LT’s from 
DDT’ a and may also be used to modify existing LT's or to create new LT's from 
existing LT's, The DOC utilizes the LT's to retrieve the required data elements 
frcm the AWA, reformats them according to the format specif icabions contained in 
the DDT, merges them with the forma, and transmits the completed forms to the 
Daoonios, The DOC oan also modify LT's but cannot create a default LT from the 
DDT, The data organization and flow are shown in figure 2-6. 
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DOCUMENT = RFP, SEGMENT = ASCENT 


Lift-off from [ 3 oooura at [ ] seconds after solid rocket booster (SRB) 

ignition (GET = [ ] seconds) after which a vertioal rise to tower clearance 

phase is initiated, ending at a relabivt- velocity of [ ] fps (GET s C ] 

seconds). After tower clearance, a controlled pitchover program is initiated to 
achieve MECO targets while reducing aerodynamic loads. A roEximura dynamic 
pressure of [ ] Ib/ft squared is achieved at a GET of [ ] seconds (geodetic 

altitude [ ] feet, alpha [ ], beta [ ], Barth relative velocity [ ] 

fos) , 


Figure 2-1,- Sample fom, 


Eleld— , , 

NAME 

TYPE 

REPEAT FLAG 

DIMENSION 

FORMAT 

DESCRIPTION 


D.e.afir.lp.tj}-cin 

Name of the variable as defined by the. document segment 
designer 

Type of data element in AWA 

Indicates arrays to be presented in columnar table format 

Maximum number of occurrences provided for in the form 

Format by which variable 1s to be displayed in completed docu- 
ment segment 

l|0-charaoter description of variable for user prompting 


Figure 2-2. - Document descriptor table definition. 
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, Name- 

yvpe, 

Repeat 

Plpiepsity , ■■■ Fprmab, 

Po,sociJ),tl^n,, 

LSITE 

C6 


A3 

Launch site 

TIjO 

R 


TO; Ot 0:3.1 

Time of lift-off (GET) 

TLO 

R 


TO:O:0i3. 1 

Time of lift-off (GET) 

RELVEL 

R 


13 

Relative velocity 

TOLNCE 

R 


TO; 0:0; 3.1 

Time of tower clearance 

HAXQPR 

R 


13 

Maximum dynamic pressure 

TMAXQ 

R 


T0;0:0;l|.1 

Time of max Q 

GDALT 

R 


15 

Geodetio altitude 

ALPHA 

R 


F5.1 

Flightpath angle 

BETA 

R 


F*t. 1 

Sideslip 

ERVEL 

R 



Earth-relative velocity 


Figure 2-3*- Doeiment descriptor table sample. 
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EfissrlBUflEi 

CLASS SET - 2 to indicate memory resident data element 

TYPE FDS Executive data typo 

NAME Name of variable used to satify the parameter 

SET = 0 if LITERAL is input 

I/O I/O flag. SET = 2 to indicate input 

IDIM Di 0 ension(s) 


Figure 2-4,- Linkage table. 
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.gjLaag 

2 

2 

2 

2 

2 

2 

2 

2 

2 

2 

2 


lyxia 

5 

2 

2 

2 

2 

2 

2 

2 

2 

2 

2 


— USi^ 

LNCHS 2 
TLNCH 2 
TLNCH 2 
SUMTAB(6) 2 
SUMTAB(7) 2 
SUMTAB(12) 2 
SUMTAB(13) 2 
P0S(3) 2 
ALPHA 2 
BETA 2 
VEL(1) 2 


Figure 2-5.- Sample linkage table. 


1 

1 

1 

1 

1 

1 
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1 

1 

1 

1 


2-5 



9“2 



HP21HX 

disk 


Daconi cs 
disk 


Figure 2-6.- Data organization and flow. 
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3.0 

The seraiautomated documentation process consists of four major steps. These 
steps do not Include the execution of the FDS processors to provide the required 
data . 


3 . 1 CONSTRUCTION OF FORM AND DDT 

The first step is the design of the standard aegnent and the construction of the 
form and its associated DDT. The definition of a segment is a task of the docu- 
ment designer. It may consist of a single table or may be an entire section of 
a document several pages in length. Segments are designed such that they may be 
used as building blocks to produce documentation for a variety of flights, For 
example, a rendezvous segment may appear once, twice, or not at all in a docu- 
ment depending on the particular flight profile. 

The form is developed in the exact format desired in the final document, with 
the oorreot number of blank spaces set aside to receive the needed variable 
data. 

This form is stored and maintained on the Daconios mass storage system for use 
by the DOC, and is under strict configuration control. The DDT is developed at 
the same time, also by the document designer, and is stored on the Daoonics 
system. The DDT is also under configuration control, and any maintenance on it 
is carried out by Daconios operations, but a copy of each DDT is also 
transmitted to the HP21MX and reformatted there for use by the DOC, 

The forms and DDT's are constructed and maintained using the standard Daconios 
document create, edit, and storage operations. 


3.2 CONSTRUCTION OF DEFAULT LINKAGE TABLES 

After the DDT has been placed in an HP21MX file, the LT can be constructed. 

The LTBLD is executed for the initial creation of the default LT. Given the 
desired document and segment Identifiers, the LTBLD determines the name of the 
desired DDT file and retrieves the DDT. The LTBLD then obtains the characteris- 
tics of the desired data elements from the DDT and prf pts the user for the val- 
ues required to complete the LT. The user may either ,.upply the names of the 
required AWA data elements or, as an option, may directly supply literal values 
that are to appear in the conpleted document, or may "null” the entry, The LTBLD 
will normai,ly be executed once for eaoh DDT or eaoh release of a new version of 
a DDT. 


3,3 MODIFICATION OR COMPLETION OF LINKAGE TABLES 

If a user needs an LT in a form different fron the default table, he may create 
a new table or make temporary changes to the default table for use during the 
current session. 


3-1 



77FM18:V 


After the LT is retrieved , the user is given the opportunity to make changes to 
the values in the table. If he elects bo make changes, he may then choose bo 
make those effective fbr the current session only, or make them permanent by 
creating a new LT. He may also elect to recreate the source LT if it (the 
source LT) was created initially by him. 


3.4 CONSTRUCTION OP COMPLETED DOCUMENT SEGMENT 

Given the existence of a form, DDT, LT, and the required data elements for a 
given segment, the DOC is executed to combine these ingredients into a oompleted 
document segment, The user specifies the document segment bo be constructed by 
supplying the document and segment identifiers. Directories of existing docu- 
ment and segment identifiers are searched to ensure that the requests are valid , 
and to obtain a two-character code associated with each identifier, These codes 
are used to check the validity of supplied LT's and to construct default names 
for the various files that are used Internally by the DOC, 

The DOG then retrieves the specified data from the AWA, The data are retrieved 

in the format in which they are specified in the LT (stored in the AWA), TlV;y 
must then be converted Into the formats specified in the DDT, The converted 
data are then ready to be inserted into the blank spaces in the form. 

Since the form is retained on the Daoonics mass storage system, a request for 
the fom for the current document segment is sent via the data channel to the 
Daoonics. If the Daoonics is up and the form file is available, the form is 
sent to the HP21MX and the data are merged with the form. The completed segment 

is then made available for review by the user. The user may then elect to (1) 

send the segment to Daoonics without review, (2) review it on his tenninal and 
then transmit it, or (3) review it and not send it to Daoonics. 


3.5 EDITING AND PRINTING 

After the merged file is returned to the Daoonics, the Daoonics operation is 
notified that the file is available, and the file name is provided. If editing 
is required (e.g,, suppression of extraneous blanks), this is carried out by the 
Daoonios operation , 

When the file is ready for printing, it is printed on the Daoonics printer and 
returned to the engineer for review, These printed segments are then accumulat- 
ed, any plots and figures prepared separately are Inserted, a table of contents 
is printed, and the signoff copy is ready for approval. 
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4.0 flssmm:oMs..iNg. m & uiqw &. 

A sucoessful execution of the documentation processor is depenaent on the 

following conditions being satisfied, 

a. A form for the requested document segment must exist on the Daoonlos mass 
storage system, 

b. The associated DDT must exist, and must reside in the correct format, on the 
Daconios. 

0 . A default LT must exist on the HP21MX. 

d. The associated prompt file must exist on the HPS’tMX. 

e. The version numbers of the form, DDT, prompt file, and LT must all agree. 

f. LT's can be created from LT’s belonging to other users, but only those 
belonging to the current user may be purged or modified and recreated. 

g. Only data elements appearing in the AWA can be retrieved for use by the DOC; 
disk resident data elements (DRDB) cannot be accessed directly. 

h. The FDS data type for each data element must be specified in the DDT and 
correspond to the type in the AWA. 

1. All data elements to be displayed in time format must be stored as real 
seconds . 

j. No units conversions are performed by the DOC except time conversions. Since 

time may be displayed in a variety of formats, the DOG will perform the time 

conversions specified by the format specification in the DDT . 

k. The HP21MX must be able to ooramunicate with the Daconios (i.e,, all compo- 
nents must be up) , and the required form file must be available on the 
Daconios files . 

l. The FDS-1 DOC will be limited to 6*1 variable names per segment. 
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5.0 ,5ySIE^l,.RE0^JlflE^^EWT■a 


5.1 OPERATIONAL REQUIREMENTS 

The DOC will be operational during the normal FDS operational periods. To be 
able bo complete the oonstruotion of a dooument segment, the Daoonloa system and 
the connecting data channel must be available. The required form files must 
also be available on the Daoonlos on-line file system. If the form file oannot 
be retrieved during a session, the user may either retrieve the data for review 
only or may terainate the session . 

In the event that a magnetic tape Interface Is to be used as an alternative to 
the data channel Interfaces, the required form must be available on tape, and a 
tape drive must be available on the HP21MX. If a hard copy of the completed 
segment Is required from the HP21MX, access to the line printer will be required 
by the DOC, 


5.2 HW/SW CONFIGURATION REQUIREMENTS 

The hardware required for the operation of the DOC consists of the HP21MX, its 
disk subsystem, and one Interactive terminal, plus the Daoonloa computer, Its 
disk subsystem, a oore-bo~core data channel connecting the two computers, and a 
Daoonics terminal. A Daoonlos terminal and the line printer are also needed for 
editing and printing the completed segment. 

The FDS software configuration consists of the standard EDS Executive and the 
supporting software required for Its operation plus: 

a. The file manager and FORTRAN interface 

b. The FORTRAN I/O package 

c. The driver for the data channel 

d. LTBLD and DOC 

The Daoonics software will consist of the standard document create and modify 
software and the interface to the data channel, 

In addition, the standard FDS Interface Table Editor (ITE) will be used for all 
linkage table creation and modification operations. A special modified version 
of the ITS control program will be used to permit the ITE to handle the linkage 
table operations. 


6.3 USER INTERFACE REQUIREMENTS 

All user Interaction with the DOC will be via a standard FDS terminal . The user 
interface will be designed to minimize the typing required of the user. Default 
file and table names are generated internally from the requested document and 
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siBgment identifiers. When the processors ask for file or table names, a user re- 
sponse of '* space- oarri age return” will result in the default names being used, 

If other names are to be used, the user would respond with the desired name. 

When the processor asks whether or not to exercise an optional oapability (e.g,, 
list a file?), the null response will indicate the "Yes” ohoioe and is assumed 
to be the nominal response in a production environment. 


5,*l DATA STORAGE REQUIREMENTS 

Eor the purpose of data storage estimating, it is assumed that there will be 10 
documents defined in the system, and the documents will average 20 segments 
each. It is further assumed that the average segment is 2 pages in length and 
contains 65 data elements. With these assumptions, there will be 200 forms 
stored on the Daoonlos requiring 1.5 million characters and 200 DDT’s requiring 
0,9 million characters. 

On the HP21MX, there will be 200 reformatted DDT's requiring 1.5 million 
characters, and at least 200 LT's requiring 0.2 million characters; this 
assuming that all users use the same set of default LT's, If we assume that 
there are 10 users and each has his own set of LT’s, then there would be 2000 
LT's requiring 2 million characters, Reality will probably be nearer the first 
assumption, with approximately 500 LT's. Then the total HP21MX storage would be 
700 files and 2 million characters. 
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6.0 CENERAL SQETWARE JVND. MIA_OriaAmAIIO Jl 


6.1 DACONICS 


6.1.1 Software, 

Two , 'separate software oapabillties residing on the Daoonios are used In 
support of the DOC. These are the standard Daoonios editing software and 
the driver for the Daoonios/HP21MX data channel. 

The standard editing software is used for the creation and maintenance of the 
DDT files, and for any editing that may be required on the final merged document 
segments prior to printing, 

The data channel driver is a special- purpose set of software, also provided by 
Daoonios, whose purpose is to provide the interface between the Daoonics 
operating system and the I/O channel that connects the Daoonios to the HP21MX. 


6.1.2 J3ai^iLia..sgLaiLLfeg. 

The four types of files residing on the Daoonios mass storage system are as 

follows . 

a. Form files - A form file exists for every document segment to be produced by 
the DOC, Form files are characterized by the existence of the static 
structure of the segment and the reserved spaces into which the data are to 
be placed ( fig . 2-1 ) . 

b. DDT files - A DDT exists for each fom file, A DDT is a structured file, 
consisting of columns of information desorlbing the data elements to be 
inserted Into the reserved spaces in the form (fig, 2-3). 

c. Static files - Static files are created for any portions of a document that 

remain unchanged fron one printing of a document to the next. These files 

are created, maintained, and used exclusively on the Daconlos, An example 
of a static file is a glossary of terns appearing in a given document. 

d. Merged files - After a segment has been processed, the merged result is 

stored on a named file on the Daconlos, 



TTFMiesV 


6.2 HP21MX 


6.2.1 gtfjCtMflrg. 

Only that software that is uniquely used for documentation prooesaing will be 
described here. Those software elements that are shared with other funrtions 
will simply be identified , 


6.2. 1.1 Shared Software 

a. RIB file manager 

b. HTE Executive 
0 . FORTRAN I/O 

d, FDS Executive 

e. FDS Interface Table Editor 


6.2. 1.2 Unique Software 

a. Linkage table build program (LTBLD) - The LTBIJ) runs as a stand-alone program 
under the RTE operating system. It is used for the creation and maintenance 
of default linkage table files. The LTBLD contains an unmodified copy of the 
FDS Interface Table Editor, which perfoms all the actual linkage table 
creation and roodifioation operations. 

b. Documentation processor - The DOC runs as a processor under the FDS Exec- 
utive and provides the following capabilities; 

(1) Modification of linkage tables 

(2) Communications with Daoonlos 

(3) Retrieval of data from AWA 

(4) Reformatting of data 

(5) Insertion of data into reserved spaces in forms 

c. Daconics driver - The Daconics driver is a set of special-purpose software 
that will permit communication between the HP21MX programs and the data 
channel to the Daconics. This driver is documented in section TBD, 


6-2 



77FM18;V 


6<2,2 J)Q, ta 

The LTBLD and DCC use three types of da*-i elements ^diaU files) on the HP21MX. 

These are PROMPT files, LINKAGE TABLE tiles, and direotories, 

a. PROMPT files - When a DDT is brought fron the Daoonica to the HP21MX, it is 
restructured into the form of a PROMPT file, PROMPT files are used by the 
Linkage Table Editor, and their format is dictated by the FDS Interface 
Table Editor (the Linkage Table Editor is actually a copy of the Interface 
Table Editor), In addition to being used for prompting, information 
contained in the PROMPT file is used in the initial creation of the default 
linkage table, and to define the format conversions and data reordering to 
be done by the DOC, One PROMPT file exists per document segment, 

b. LINKAGE TABLE files - Linkage tables establish the name reli. tlonships be- 
tween the reserved spaces in the forms and the named data elements in the 
AWA. They also contain all the information required by the FDS Executive 
for retrieval of the needed data from the AWA. The linkage tables are 
retained on disk in the form of permanent files. The LT files are either 
named aui.omatioally using the document, segment, and user identifiers, or 
may be named by the user. At least one LT exists for each segment, bub mul- 
tiple LT's may exist per segm'int. 

0, Direotories - Due to the potentially large number of files created and used 
by the DOC, direotories of valid files are maintained to faoilitate file name 
validation and error oheoklng, These directories are as follows: 

(1) Document ID - The document ID directory contains a list of all valid 
four-oharacter document identifiers, the associated two-character docu- 
ment codes, and the fUll document titles, 

(2) Segment ID - The segment ID directory contains a list of all valid 
four- character segment identifiers, the associated two-charaoter 
segment code, the two-oharaoter document code that identifies the docu- 
ment which contains the segment, and the segment name. 

(3) LINKAGE TABLE and PROMPT file - Both the LINKAGE TABLE files and PROMPT 
files appear in this directory. The full six-character file name 
appears, along with the two-character document and segment codes. This 
permits not only the testing for the existence of a requested linkage 
table, but also the determination that it is associated vrith the cur- 
rent document and segment to be created . 
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7,0 LINItAQE TABLE BUILD , PROgRAH-a^,Tg,LPJ. 


7,1 PUB POSE 

The principal purpose of the LTBLD Is to create default linkage tables from 
DOT'S. It also creates, at the same time, an assooif>ted PROMPT file that is 
used Internally whenever modifications are made to a linkage table. 

As a L condary purpose, it can also create new linkage tables from existing 
ones, but this is more commonly done by the documentation proces.'»oir' (DOC). 


7.? FUNCTIONAL DESCRIPTION 

The LTBLD utilizes a copy of the PDS Interface Table Editor for the creation and 
modification of LT's. No changes were made to the Interface Table Editor when 
it was incorporated into the LTBLD to function as a Linkage Table Editor , so all 
capabilities and restrictions are as documented In the SDD volume I (rev. 1, 
see 3.^), and will not be reproduced here, A list of prompts and commands will 
be included, however, for user convenience. 

The function of the remaining portion of the LTBLD is to determine the source 
file to be used by the editor, and the destination file for the results of the 
editing process. 

The editor can construct LT's frcm any of the following sources: 

a, DDT 

b. Default LT 

0 , User- owned LT 

d. LT belonging to another user 

It can then produce the following output LT files: 

a. Default 

b . User-owned default 

0 . User-owned nondefault 

Due to the potentially large number of FORM, DDT, PROMPT, and LINKAGE TABLE 
files, a naming convention has been developed to minimize user typing and file- 
name confusion . 

When a new document is to be added to the system, the originating organization 
assigns a document ID. This ID can be from one to six characters long. When 
the form and DDT for a new segment is developed, a similar ID is asa^gned to 
that segment. All subsequent user references to a document segment utilizes 
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these two ID's, In addition, each document and segment has a two-oharaoter ID 
associated with it for internal use by the program. 

At the time that each document and segment is added to the system, the two- 
character doouDisnt ID and a two-character segment ID is assigned. When a user 
signs on to th'e LTBLD and identifies the document and segment for which an LT is 
to be built, these two ID*s are retrieved fran the document and segment 
directories. They are subsequently used fbr validation of all input file 
requests, and for the creation of all default file names. 

All PROMPT and LINKAGE TABLE files are constructed from three parts; (1) the 
first character, (2) the middle four characters, and (3) the last character. 

The first character of all PROMPT file names is a ”P," and for all LINKAGE TABLE 
files it is an "L,“ This character is provided by the program and is never 
input by the user, 

The middle four characters of all default file names are the two-character ID's, 
For nondefault names, the user supplies those four characters. 

The last character indicates ownership of the file, and is the one-character 
user ID (except for the PROMPT file and the default LINKAGE TABLE file, which is 
created directly frcm the DDT), These files are user- independent, and are 
indicated by an for a last character. 

In the normal operational environment, the LTBLD will use DDT's to produce de- 
fault LT's. The other capabilities are available should they be needed, but 
will normally be functions performed by the DOC, 

The user initiates the process by supplying his one-character user ID and the 
six-character document and segment ID's. He then must select either the DDT or 
an LT as the source file for the editor. If the DDT la selected, the DDT for 
the requested document segment is rebrieved, and uhe data elements are placed 
into the default LT, 

If the existing LT option is selected, the user is prompted for the input and 
output LT names. The responses are checked for validity, and the requested LT 
is retrieved from mass storagp 

The Linkage Table Editor then prompts the user for any missing values. Values 
may be entered, changed, or deleted, according to the rules documented in SDD 
volume I (rev. 1, sec, 3*^), Note that only values are accessible to the user. 
The characteristics are obtained frcm the DDT, which is under configuration con- 
trol, so changes to the characteristics are accomplished by altering the DDT and 
then recreating the default LT, 

When the user indicates that he is finished with the editor, the new LT file is 
created, and its name is added to the directory. The program la then 
terminated . 
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7.3 ASSUMPTIONS AND LIMITATIONS 

a. Tha requested dooument Identifier must appear in the direotory. 

b. The requested segment identifier must appear in the direotory, and must 
be assoeiated with the requested dooument, 

0 . Any requested DDT must be present on the Daoonios, 

d. Any requested source LT must bo present on the HP21MX, 

e. The name of any requested source LT must exist in the LT direotory, and 
the associated dooument and segment ID's must agree with the document 
and segment fbr which the current LT is to be used. 

f. LT’s may be created from any other LT (for that segment), including 
those owned by other user a. 

g. LT's may be recreated or purged only if they belong to the current 
user. 

h. Any requested LT must have the same cycle number as the PROMPT file for 
that segment, 

1. Any oreated LT's will have the user's ID appended as the last oharaoter 
of the file name except the default LT, which is user-independent, 


7.4 PROGRAM INPUT/OUTPUT VARIABLES 

Since LTBLD is a stand-alone program and does not execute under the FDS Execu- 
tive, it does not have an associated interface table. 

All inputs to the LTBLD are prompted inputs, Vfhen a "yes/no" response is 
required, the default response is always "yes" Ci,e,, a response of "space, car- 
riage return" will result in the "yea" option being executed). All input errors 
will result in appropriate messages being displayed at the user's terminal, and 
the user is then given an opportunity to correct the erroneous input. The user 
may terminate a session at any point by responding to any prompt with a Any 

nonrecoverable error oonditions, such as enoountering an error while reading a 
disk file, will result in a diagnostic message followed by termination of the 
run . 


A list of prompts, acceptable responses, and the resulting action, is shown in 
table 7,4-1. 

Since the Linkage Table Editor is identical to the FDS Interface Table Editor, 
it is not necessary to duplicate the entire editor docimentation . However, for 
user convenience, the section that describes the editor prompts and user 
responses is duplicated in section ?.4.3> 
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TABLE 7.^-1.- PROGRAM SOLICITED (PROMPTED) II3PDTS 


PROGRAM LTBLP 


* Prcopt 

1 

I 

5 . Mesnirjff 

I 

Valid reSDonses 1 

? ENTEH DOCUMENT ID 

i List directory 

i 

1 

1 

? ’ 
Six-character document ID { 

\ ARE YOU ADDING A NEW DOCUMENT 
( TO THE SYSTEM? 

1 

\ Prompt for new 
1 documeot ID 

t 

Yes 

1 

t 

r 

f 

1 

; 

1 

1 

i Heprompt 
[ 

No 

1 

1 

: 

1 

i J 

T 1 

\ ENTER NEW THO-CHAHACTER ID \ 

1 1 

Two-character document code ? 

1 1 

ESTER DOCUMENT DESCHIPTIffi) ! 

! (OP TO 40 CHARACTERS) ! 

1 i 

Document description ' 

! ENTER SEGMENT ID 

1 

* List directory 

1 

7 * 

Six- character document ID \ 

t 

? ARE YOU ADDING A NEW SEGMENT 
TO THE SYSTEM? 

' Prompt for new 

? segment ID 
1 

Yes 

f 

1 

1 

1 

E 

t 


* Reprrsjpt 

1 

No 

S 

r 

! ENTER NEW TWO-CHARACTER SEGMENT JO 

I 

j 

1 

1 

t 

t 

Two-character segaent ID * 

1 

_ . r 

t 1 t 

! ENTER SEGMENT DESCRIPTION 1 ' 

! (UP TO 48 CHARACTERS) r 

1 t 1 

Segment description 


\ USE DDT? 

] 

1 

* Create master 
{ default LT from DDT 

Yes 



* Use existing LT 

! as the source 

1 

No 

f 

f DISPLAY DDT? { ' 

1 1 1 

) I 1 

1 1 j 

Yes ! 

No * 
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TABLE 7.^-1.- Concluded 



PROGRAM _ 



1 PrCIBDt 

I 

1 

1 Heaninc 

A 

r 

\ Valid resDonses 

1 

1 

1 

.1 

1 ENTEB SOUBCE LINKAGE TAB[£ NAME 

j 

1 

1 

1 Use default LT 
1 
1 

{ Use user-default LT 

r 

f 

] Use specified LT 

1 

1 

I Use specified LT 
[ that belongs to a 
1 different user 
1 

i List directory 

1 

r 

1 

1 

1 Space - carriage return 

5 

f Space - user ID 

1 

1 

1 Four-character LT name 

t 

t 

1 Five-character LT name 

1 

I 

I 

1 

1 

i ? 

1 

1 _ . 

1 

I 

r 

f 

I 

t 

1 

1 

1 

t 

1 

1 

1 

f 

c 

f 

( 

t 

1 

1 

1 

1 

1 

! INPUT NEW LINKAGE TABLE NAME 
j 

j 

1 

1 

I Create laaster 

5 default table 
1 
1 

{ Create user-default 

1 table 
1 
1 

*1 Create named table 

1 

1 List directory 

r 

r 

1 

1 Space - carriage return 
\ 

\ 

! Space - user ID 

\ 

1 

1 

{ Four- character name 

i 

J 

* ? 

1 

1 

1 

1 

t 

1 

i 

t 

i 

1 

1 

1 

t 

1 

1 

( 

I 

1 

1 

1 

_1 

! DO YOU WANT TO HE-CREATE THIS LT 

1 Purge existing LT 
1 and create new one 
\ with same name 

t 

1 

} Reproflpt user for 

\ new LT name 

1 

1 _ 

1 

1 

i Yes 

r 

t 

I 

1 

1 

t 

! No 

f 

1 

r 

1 

\ 

i ENKR FILE DESCRIPTION 

f 

I 

1 

( 

f File description 


! (UP TO U8 CHARACTERS) 

( 

r 

9 

1 

1 

I 

t 

1 


1 DELETE FILE XXXXXX? 

( 

! Delete source 

1 

4 

i Yes 



1 LT file 
1 

( 

1 

1 



1 

J Retain source LT 

I 

! No 

1 

1 



I 

U1 


:;OTg: In response to any proapt, a user { 

input of a will terminate the * 
run. } 
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Displays 

The only displays produced by the LTBLD are listings of directories, linkage 
tables, and DDT's. Directory listings are obtained by responding with a 
"?” when prompted for a document ID, segment ID, or linkage table name. 
Examples of a Document ID Directory, a Segment ID Directory, and a Linkage 
Table Directory are shown in figures 7. ^*1-1, 7.^. 1-2, and 7. *1.1-3. 

The linkage table listing is obtained by invoking the "LIST** command while 
executing the Linkage Table Editor, 

A sample linkage table is shown in figure 7.*1.1-*1. 

The DDT liating is obtained by responding with a null response when prompted 
by the program with the prompt "LIST DDT?" A sample DDT is shown in figure 
7.H.1-5. 

In addition to these displays, various messages are produced that inform 
the user of error conditions or the completion of significant tasks, such 
as the creation of a file. These messages are shown in table 7. *1.1-1. 
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TABLE PSOGBAM MESSA(S TABLE 

PflOGRAM LTBLD 



MSG 

no. 

i 

t 

i Message 
1 ID block 

f 

r 

c 

1 

1 

1 

t 

t 

Message text block and explanation 



1 

f 

1 

1 

1 

1 

I 

1 

1 

T 

J 

f 

REQUESTED DOCUHENT DOES HOT EXIST. 



2 

X 

X 

t 

1 

1 

' 

1 

< 

1 

1 

DOCUMENT CODE XX ALREADI EXISTS. IQU MUST SELECT AJIOTHEH CODE, 



3 

1 

1 

i 

1 

1 

1 

i 

1 

1 

1 

REQUESTED SEGKEKT DOES HOT EXIST FOR THIS SEGMENT. 



4 

f 

t 

1 

1 

r 

j 

1 

1 

1 

1 

f 

SEGMENT CODE ALHEADI EXISTS FOR THIS DOCUt-SENT. IDO MDET SELECT /*^THEH CODE. 



5 

1 

1 

f 

1 

1 

— t- 

T 

1 

1 

I 

t 

YOU HAVE REQUESTED SGMEOIE ELSE'S DEFAULT TAELS. 



6 

t 

r 

» 

1 

I 

f 

1 

I 

1 

i 

t 

UNABLE TO OPEN LINKAGE TABLE DIHECTORI, lEBR = XX (FATAL ERROR) 


1 

B 

i 

1 

r 

t 

1 

1 

1 

1 

f 

1 

REQUESTED LT NAME NOT IN DIRECTORY. 



6 

1 

1 

r 

1 

f 

— t . 

i 

1 

1 

1 

1 

X ■ 

REQUESTED LT IS IHDT FOR REQUESTED DOCUHEHT AND SEGMENT. 



9 

i 

t 

1 

1 

1 

r 

» 

t 

T 

1 

I 

SEARCH FOR COMPATIBLE LIKKACE TABLE ABANDONED, 



10 

X 

1 

r 

1 

1 

» 

f 

r 

i 

1 

f 

LINKAGE TABLE XXXXXX ALREADT EXISTS. 



n 

t 

t 

f 

1 

1 

♦ 

1 

r 

1 

r 

i 

- X 

REQUESTED LT NAME DOES NOT PRESENTLY EXIST. 


1 


1 

1 

1 

1 

1 

1 

t 

1 

1 

I 

1 

1 

» 

r 

f 

A aiJKACS TABLE NT MED XXXXXX ALREADY EXISTS FOR AtiOTHER DOCUMENT AND SEGMENT. 
YOU MUSI SELECT ANOTHER NAME. 


I 

B 

1 

1 

1 

1 

1 

r 

1 

1 

1 

1 

t 

r-L. 

YOU HAY HOT CREATE A TABLE HUH ANOTHER USER’S ID. 




i 

1 

i 

1 

1 

1 

r 

r 

I 

p 

r 

i 

f 

1 

DACONICS INPUT FILE HAMS IS XXXXXX; XXXXXX: DDT. 
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TABLE Concluded 


PROGRAM . 


flessase text block end explanation 


I/O ERROR IN DACIG. lERR = XX 


FILE XXXXXX SUCCESSFGLLX CREATED. 


FILE XXXXXX BEING ADDED TO THE DIRECTOR!. 


FILE XmXX DELETED. 
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DOCUMENT DOCUMENT DOCUMENT 


ACRONYM 

ID 

TITLE 

PRFP 

PP 

PRELIMINARY REFERENCE FLIGHT PROFILE 

RFP 

RP 

REFERENCE FLIGHl' PROFILE 

CFP 

CP 

CONCEPTUAL FLIGHT PLAN 

OFP 

OP 

OPERATIONAL FLIGHT PLAN 


Figure 7. 4. 1-1.- Document ID Directory. 


SEGMENT 

DOCUMENT 

SEG 

SEGMENT 

ACRONYM 

ACRONYM 

ID 

TITLE 

INTHOD 

PRFP 

IN 

INTRODUCTION 

ASCENT 

PRFP 

AP 

ASCENT PHASE 

ONORBT 

PRFP 

00 

ON-ORBIT PHASE 

RBNDEZ 

PRFP 

RZ 

RENDEZVOUS PHASE 

DEORB 

PRFP 

DO 

DE-ORBIT PHASE 

TAB3I 

PRFP 

CT 

CONSUMABLES TIMELINE TABLE 


Figure 7.4. 1-2.- Segment ID Directory. 


NAME DOC SEC V DESCRIPTION 

LPPAPG PRFP ASCENT PP AP 1 CONTAINS ALL LITERALS FOR TESTING DOC 

LLITTG PRFP ASCENT PP AP 1 CONTAINS ALL LITERALS FOR TESTING DOC 

PPPAP* PRFP ASCENT PP AP 1 PROMPT PILE FOR PRFP, ASCENT 

LPPAP» PRFP ASCENT PP AP 1 EMPTY LINKAGE TABLE 

INPUT NEW LINKAGE TABLE NAME x% 


Figure 7.4. 1-3.- Linkage Table Directory. 
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LPPAP* - INCOMPLlilTE INTERFACE TABLE FOR VERSION 1 of PPAP* 

LSITETs "ABCDEF '• 

TLO s A 

TID = B 

RELVELs C 
TCLNCE= D 
MAXQPRs E 
TMAXQ = F 

GDALT = 0 

ALPHA = I. 23 OOOOE+O 2 
BETA = H 

ERVEL = I 

FLNAMEs 0110501 

LOCATES 9, 28, 77 

EVENT = 0 

GMT = P 

GET = U 

POSVECs V 

CMNTS = 


Figure 7**t»l-^*” Linkage table listing. 


DATA DATA COLUMN DIMENSION FORMAT DESCRIPTION 

NAME TYPE FLAG 


LSITETC 

18 

1 

A3 

LAUNCH SITE 

TLO R 


1 

T0;0:0:3.1 

TIME OF LIFTOFF (GET) 

TLO R 


1 

T0:0:0:3. 1 

TIME OF LIFTOFF (GET) 

RELVELR 


1 

13 

RELATIVE VELOCITY 

TCLNCER 


1 

T0:0:0:3. 1 

TIME OF TOWER CLEARANCE 

MAXQPRR 


1 

13 

MAXIMUM DYNAMIC PRESSURE 

TMAXQ R 


1 

T0:0;0:lt. 1 

TIME OF MAXIMUM DYNAMIC 





PRESSURE 

GDALT R 


1 

15 

GEODETIC ALTITUDE 

ALPHA R 


1 

F5. 1 

FLIGHT PATH ANGLE 

BETA R 


1 

F4. 1 

ANGLE OF SIDESLIP 

ERVEL R 


1 

14 

EARTH RELATIVE VELOCITY 

FLNAMEC 

6 

1 

A5 

FLIGHT NAME 

LODATEI 


3 

12 

DATE OF LIFTOFF 

EVENT C 

36 » 

10 

A 36 

EVENT NAME 

GMT R 


10 

T0:2:2;2 

GMT OF EVENT 

GET R 


10 

T0;2:2:2 

GET OF EVENT 

LAT R 


10 

F 6 . 1 

GEODETIC POLAR POSITION VECTOR 

LONG R 


10 

F 6 . 1 

GEODETIC POLAR POSITION VECTOR 

ALT R 


10 

F 6 . 1 

GEODETIC POLAR POSITION VECTOR 

CMNTS C 

18 * 

10 

A 12 

COMMENTS 


INPUT NEW LINKAGE TABLE NAME : 

Figure 7.^. 1-5.- DDT for document PRFP, segment ascent. 
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,EUg Outpiiiba 

The LTBLD produces LINKAGE TABLE files and PROMPT files. Since these files are 
only used internally by the documentation processor, and are not in a format 
that is directly usable by a user, their format is documented in the documenta- 
tion for the subroutines which produce them. 

In addition, entries are made in the appropriate directories as documents, 
segments, and linkage tabl ir , and are added to the system. The formats of these 
directories are shown in v^etion 7,4.1. 


7.4.3 Linkage. Table Editor. Prompts 

a. Syntax 

(1) NsCuser response) A 

(2) \parameter keyword |=| s(user response) A 

(3) \parametor keyword r {label[(sub,[sub3)]S ; (user resi; ,:se)A 

(literal list ) 

b. Purpose - The table edit directives allow the FDS user to enter new parameter 
values or labels, and/or to modify existing values or labels in a specified 
linkage table. When the editor is entered, the user is prompted with 
syntax 2 , The user is normally prompted only for those parameters with 
either missing or incomplete data. However, the user can control the 
prompt mode with the PROMPT directive (SDD vol. I, rev. 1, sec. 3.4.4), 

If any other prompt mode is selected, the user will be prompted with 
either syntax 2 or syntax 3, depending upon whether or not the parameter 
being displayed has associated values or labels. 

0 . Definitions 


( 1 ) User responses for syntax ( 1 ) 


/ executive responses 
I editor directives 




parameter keyword = 


(& 

( label! (sub, [sub])] ' 
[literal list 


(a) Executive responses - A one-character response causing executive 
action. The options are as follows: 


(?) 
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A list of all available Linkage Table Editor directives is 
displayed, (Note.* For syntax 2 and syntax 3, this response 
will cause the syntax of the appropriate statement to be 
displayed, } 

(.%) 

Abnormally terminates the Linkage Table Editor, and all modifi- 
cations are discarded, 

U) 

A carriage return onlyj causes no change. If in response to 
syntax 1, the user will be reprompted with the (\;) symbol. 

If in response to either syntax 2 or syntax 3, the next applicable 
parameter will be prompted, 

(\) 

A user request to be prompted with only the (\:) symbol (syntax 
1), This action removes the user from the editor prompting 
mode, and allows the modification of any selected parameter 
in the table or use of any editor directive. To be placed 
back into the editor prompt mode, the user must use the PROMPT 
directive (SDD vol, I, rev. 1, sec, 

(b) Editor directives ~ See sections 3.^,3, and 3.^.5 of 

SDP volume I, rev. 1. 

(o) Parameter keyword - An alphanumeric name of up to six characters 
identifying one of the parameters in the linkage table being 
edited. The keyword must match an existing keyword in the 
table or no aetion is taken and the user is reprompted with 
the (\ ; ) symbol . 

The (=) symbol is used to denote an input parameter. 

The field, label [(sub,[3ub])] , la an alphanumeric name of 
up to six characters identifying a data element to be located 
at processor execution time and used as a set of input parameters. 
The label may be optionally subscripted , in which case the 
subscript identifies the initial array position to find the 
first input value, or to place the first output value. Subsequent 
values are found or are placed in the following contiguous 
array positions. The data elements referenced by the label 
will be checked at execution time to ensure that they are of 
the correct data type and of sufficient size to satisfy the 
parameter usage. If either the size or type checks fail, the 
user is notified, processing is terminated, and the user is 
reprompted with the (%i) symbol. Note that subscripting will 
be accomplished using the type and dimension attributes of 
the data element existing In the AWA at execution time. Data 
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elements nob then in existence may not be used as processor 
Inputs, or for processor outputs if subscripted. 




The liberal list - allows the FDS user to assign values to 
parameters. The liberal list is defined as; 

(C {sub, [sub])] value ) 

\[(sub,[sub])] repeat list) 

'symbolic string- 


f[(sub ,[sub] )] value 
,l C (sub,[sub])] repeat list 

where; 




[{sub ,[ sub])] value - an immediate input data value to be entered 
into the linkage table for this parameter. Values to be input 
must be of the predefined type for the parameter. If not, 
no action is taken, the user is notified and reprompted. The 
valid data value types are: 


- Integers consisting of numerical digits and prefixed algebraic 
sign {e.g., 1, -7f +17) 


- Single-precision real numbers consisting of numerical digits, 

a prefixed sign, and a decimal point; may also contain an embedded 
sign and the letter E {e.g., -6.213, -6.213E+01, +7.2il75E-03) 

- Double-precision real numbers consisting of numerical digits, 
a prefixed sign, a decimal point, an embedded sign, and the 
letter D {e.g., +17.32^10+03, -11.82450-07 


- Character data consisting of alphanumeric data enclosed by 
quotation marks ("). (Note; quotation marks within the character 
data are not permitted.) If the number of characters supplied 
is greater than the permissible number for that parameter, 
no action is taken, the user is notified and reprompted, If 
the number of characters supplied is less than the required 
number, the supplied data are left adjusted in the data string, 
and the remainder of the data string is padded with blanks. 
Permissible data string lengths are 2, 6, 18, 36 , or 72 characters 
{e.g., "AB" , "XYI7BC"). A parameter may consist of an array 
of character strings of any combination of the permissible 
data string lengths. Length checking and blank propagation 
is done only within a string, and is not performed on an array 
basis. 


- A null character (&) causes the existing value for this parameter 
to be set to zero, and the parameter is considered to be incomplete. 
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-A mixed type Is a combination of any of the above data typej 
ocoiirring in a fixed, predefined pattern. 

- A free type is a random combination of any of the above data 
types. No error oheoking oooura for a free data type. 


All or part of a parameter data arrry may be specified by the 
[(sub, [sub])] value, If the value i.s optionally subscripted 
(preceded by a numerical digit(s) enclosed in parentheses, 
e.g., (3)) I the value will be placed in the position of the 
parameter data array indicated by the subscript. Subsequent 
values in the list will be placed in the following contiguous 
locations unless another subscript is encountered. (Note: 

Arrays may be singly or doubly dimensioned, but the subscript 
values must be integers.) If either the subscript la greeted 
than the maximum allowable element in the list or the subsequent 
list of values extends beyond the allowable list, no action 
is taken, the user is notified and reprompted with the (N;) 
symbol , 


[(sub) [sub])] repeat list - the repeat list is defined as; 


nR /value \ 

(repeat list/ 


nR / / value ( 

y ( repeat list) 



The repeat list allows the FDS user to repeat a set of values 
a specified number of times. The subscript, if present, indicates 
the starting position in the parameter data array, the same 
as for the [(sub, [sub])] value. A repeat list is specified 
by a numerical value suffixed with the lettier R (e.g., 3R)* 

A repeat list may be a single value, a list of values, and/or 
other repeat lists. If more than one value appears in the 
repeat list, the list must be enclosed by parentheses (e.g., 

3R5) 3R(5, 7, ”AB”)). An entire repeat list may be subscripted, 
but no subscripts may appear embedded within the repeat list. 

If the entry of a literal list takes more space than is available 

on one tenninal line, the user must end the line at a component 

value (e.g,, a character string, real maiber, etc,, cannot 

be started on one line and completed on the next) followed 

by a carriage return. The Linkage Table Editor will then reprorapt 

the user with the parameter keyword and the indices of the 

next incomplete array location. For example, given the parameter 

ABC, which requires five fields, the input might look like 

the following: 
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\ABC=:"ABCDEP", 1.0,3. *1^ 

\ABCs(10: 1.75,"END"A 

Note: The mixing of values and labels Is not meaningful and 

is prohibited. If a label is provided, only one label (nob 
a list of labels) is allowed, and the parameter is considered 
to be complete. For liberal arrays, all elements must be complete 
before the parameter is considered complete. 

The symbol & indicates that any existing label for this parameter 
is removed , and the parameter is considered as incomplete . 

If used in conjuobion with a literal list, it causes individual 
element.^ within the list to be set equal to zero (blanks in 
the case of Hollerith strings), and the parameter keyword marked 
as incomplete (in this context, & may be used with subscripts 
and repeat fields) . 

The 'symbolic string' is a processor-dependent string of symbols 
to be evaluated/inter prebed by the processor at execution time 
(e.g., expressions and conditions for certain util.Hy processors, 
SDD vol. II/III (to be published)). This string of symbols 
is lexically analyzed (see SDD vol. IV) by the Linkage Table 
Editor and passed to the processor as an encoded buffer within 
the Interface table. A symbolic string may not be subscripted, 
be part of a mixed type, or be contained in a repeat list. 

If a symbolic string is longer than a terminal line, the user 
may terminate the line with a carriage return at any conponenb 
boundary (e.g., a real number, label, etc., may not be split 
over two lines). The user will then be repronpted and allowed 
to continue the input string. For example 

\EXP = ; 'TAB0UT(I)=(TAB(I)/61|)*3+2»A 
\ CONTINUE ; SIN (THET (I ) ) +E«'*2 ; I = 1 , 3 'A 

(2) User response for syntax (2) or (3) 

executive responses 
label [( sub ,[ sub] )] 
literal list 
& 

See definitions under syntax (1) response for an explanation 
of these terms. 
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7.5 LINKAGE TABLE BUILD PROGRAM (LTBLD) SUBROUTINES 

In addition to those subroutines that follow, LTBLD uses several subroutines 
that are shared with the dooumentation processor. Instead of duplicating 
the dooumentation for those subroutines here, the reader is referred to section 
6,0 of this document, 

The subroutines are: 

DACIG 

DRBAQ 

WHITG 

LTNMG 

LTNNG 

DOffcG 

LP4AG 

L'';PHG 

LTPFG 

LTMOO 

LTIFG 

LTOIG 

LTXIG 

LPRMG 
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fi;gK.r.giiLJia,tn9-r Main fi:gftr.3iiL.LTgJJ. 


Purpose 

Due bo the memory size resbriotion on the HP21MX oomputer, the Linkage Table 
Build Program is a sesnented prograin. The principal purpose of LTBLD is 
to serve as the master segment, and to direct flow through the lower segments 
that actually perform the tasks required for the creation and modification 
of linkage tables. 


7,5. 1.2 Punetional Description 

Before the first segment is called, BMPAR is called to obtain the user's terminal 
logical unit number and the user's one-character ID, These are stored in 
oommon for use by the other segments. The security code and cartridge number 
for the directory files are also stored in oommon, along with the security 
code and cartridge number for the LINKAGE TABLE and PROMPT files. One additional 
quantity is also stored in oommon that tells the lower segments that they 
are being called by ITBLD, Most of the subroutines that are used by LTBLD 
are also used by DOC, Of these, most are identical for both uses,’ however, 
a few have some restrictions when used by DOC that they do not have when 
used by LTBLD, To avoid tba creation of an excessive number of nearly identical 
subroutines, the differences are incorporated as options and are triggered 
by the variable PROFLG, which tells the subroutines which program is calling 
them. 

After each segment is called, an error flag is interrogated. If it has been 
turned on by the segment, the run is terminated immediately without calling 
the remaining segments. 


7.5. 1.3 Assumptions and Limitations 

The only assumption made by LTBLD is that the user has input his user ID 
as part of the run command. However, if this was not done, the first segment 
will detect this omission and prompt the user for this information. 


7.5, 1.4 Method 
None. 

7*5. 1.5 Routine Input/Output Variables 

The LTBLD input/output variables are presented in table 7. 5.1-1. 
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7.5. 1.6 Functional Logie Flow 

The functional logic flow for LTBLD is presented in figure 7. 5. 1-1. 


7.5. 1.7 Diagnosblos and Debug 
None . 

7.5. 1.8 Special Comments 
None . 

7.5. 1.9 References 
None. 
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LU 

USERID 

CARTRG 


JCR 

JSEQ 

PHOFLG 

ISW 


Math 

,syafcgl,. 


Intg 

Intg 

Intg 


I 

I 

0 


TABLE 7.5. 1-1 lUPUT/OUTPUT VARIABLES 
Routine _USLP__ 


JInitA 


SP 

SP 

c 



1 

t 

1 

1 

TYPE 




I 


1 

1 

1 

1 

somE, 

NOTES; 

1 

1 

Free 

Dubl 

lecH 

Mix 

i I = 

Input 

I 

1 

IT = Interface Table 


i 

1 

Intg 

2CH 

36CH 

Char 

\ 0 

Output 

1 

1 

T = Terminal 

SP - System 

Parameter 

< 

1 

1 

1 

1 

Real 

6ca 

72CH 

Bln 

} I/O 

= Input/Output 

1 

1 

t 

t 

X 

1 

A = Calling Argument 
C = Common 
F Disk File 


Unit number of user terninal, 

One-charscter user ID* 

Cartridge containing LINKAGE TABLES and 
PROMPT files. 

Security code for LINKAGE TABLE 
and PROMPT files . 

Cartridge containing directories* 

Security code for directories. 

Processor flag; set = 0 

Set = 1 for first call 
to LIKLG, 

= 2 For second call 
Segment error flag* 


SAM = System Available Memory 




Figure 7. 5, 1-1.- LTBLO functional logic flow. 
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7.5.2 .Pr, 9 i?LCgm...N.afa.g Pr off ram LlMliG 


7.5.2, 1 Purpose 

The sole purpose of LINLG is to serve as the main program of the segment 
oontalning subroutine LTMAG. LTMAG Is used by both LTBLG and DOC. However, 
the main program of any segment must contain the name of the master segment 
that called It. Therefore, to avoid duplicating LTMAG with that single 
difference, the **do-nothing" program LINLG was written, which simply calls 
LTMAG then returns to LTBLG. A similar routine also exists for DOC. 

There are no inputs, no outputs, no internal variables, and no logic structure. 


7. 5. 2. 2 Functional Description 
None . 

7. 5. 2. 3 Assumptions and Limitations 
None. 

7.5.2.»l Method 
None, 

7. 5. 2. 5 Routine Input/Outrut Variables 
None. 

7. 5. 2. 6 Functional Logic Flow 

The functional logic flow for LINLG is presented in figure 7. 5. 2-1. 

7. 5.2.7 Diagnostics and Debug 
None. 
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7 - 5 . 2.8 Special Commenta 
None, 

7. 5. 2,9 References 
None , 
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Figure 7. 5. 2-1.- LINLG functional logic flow. 
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7. 8.3 .SubxoufrJLne-Mflae-r.. LTBg.G. 


7 . 5 . 3 . 1 Purpose 

Subroutine LTBSG Is responsible for determining the name of the linkage table 
to be produced, the document segment with which the table Is associated, 
and the source of Information with which the table is to be created. A linkage 
table can either be created from an existing linkage table, or directly from 
a DDT. LTBSG obtains the six-character document and segment identifiers 
that are used in directory searches, and to construct the name of the DDT 
file on the Daoonlos. It also obtains the two-character document and segment 
codes that are used for the creation of linkage table names, and for validating 
that a requested linkage table Is for the correct document segment. 


7. 5 . 3.2 Functional Description 

The first task of LTBSG is to check for the existence of a valid user ID. 

In the event that the user failed to enter his ID correctly, LTBSG will detect 
this and issue a prompt to the user. Subroutine DOSEG is then called to 
process the user document and segment inputs. After DOSEG has stored the 
document and segment ID*s and the associated two-character codes, LTBSG asks 
the user whether he wants to use a DDT or another linkage table as the source 
of information with which to create the new linkage table. If the DDT option 
is selected, subroutine DACIG is called to retrieve the appropriate DDT from 
the Daoonlos. The user is then given the opportunity to list the DDT. If 
the linkage table option is selected, subroutine LTNMG is called to process 
the input linkage table name request. The final task is to call subroutine 
LTNNG to obtain the name of the linkage table that is to be created. 


7 . 5. 3 . 3 Assumptions and Limitations 

If the DDT input option is selected, LTBSG assumes that the appropriate steps 
have been taken to activate the communications interface between the HP21MX 
and the Daconios, and that the desired DDT is present on the Daconios on- 
line storage. In the event that either of these conditions are not met, 
an appropriate message is sent to the user and the session is terminated. 


7.5,3.'! Method 
None , 

7 . 5 . 3.5 Routine Input/Output Variables 

The LTBSG input/output variables are presented in table 7. 5.3-1. 
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7.5. 3.6 Functional Logic Flow 

The functional logic flow for LTBSG is presented in figure 7. 5. 3-1. 


7. 5. 3. 7 Diagnostics and Debug 


, ■ ■ . ftlasogatio 

DDT cannot be retrieved . 


tjoRniag 

Either communications 
channel is not active, 
or requested DOT is not 
on on-line storage on 
Daoonics . 


Reault. 

Abort 


7. 5. 3.8 Special Conments 
None . 


7. 5. 3.9 References 
None, 
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TABLE 7. 5. 3-1.- IKPUT/OUTPUT VARIABLES 
Routine LTBSG 


Code 

syabjaL 


DOCID i 

1 

1 2CH 

t 

f 

1 

I/O 1 
1 

1 c ! 

t 1 

1 Two- character document code, 
1 

1 

DOCNAM 1 

1 

1 

1 6CH 
1 

1 

i 

3 

I/O i 
1 

t 1 

1 c i 

1 1 

t 

i Six-character documoit identifier 
1 

1 

LTNAM 1 

1 

1 

[ 6CH 
1 

1 

1 

1 

1 

1 

I/O \ 
1 

j t 

1 c ; 

1 1 

1 

1 Input linkage table name. 

t 

LU i 

1 

1 Intg 
1 

t 

1 

1 

1 

X 

I 1 

1 < 

i c \ 

1 V 

1 

j User terminal logical unit, 
1 

NLTNAM 1 

1 

1 

1 6CH 
1 

1 

1 

1 

1 

I/O 1 

1 

1 t 

1 c I 

1 1 

1 

1 Output linkage table name, 
1 

SEGID i 

1 

i 2CH 

1 

1 

1 

1 

1 

I/O [ 

i 

1 1 

1 c i 

1 1 

1 

1 Two- character segment code, 

t 

SEGNAM 1 

1 

1 

i 6CH 
1 

1 

1 

r 

1 

I/O i 
1 

1 r 

\ c i 

1 t 

1 

i Six-character segment identifier. 

t 

1 

USERID 1 

1 Intg 

1 

1 

1 

I/O i 

1 X 

i C or X i 

t 

1 One-character user ID. 


Math 

.aviiibpl 


JLatS- 


_Hae_ 


Ifnlts 


Source 


Sxlernal la.bvl- 


Peflnitign 



1 

1 

TIPE 




SSL. 


NOTES: 

1 

1 

Free 

Dubl 

18CH 

Mix 

1 = Input 

XT = Interface Table 


\ 

1 

Intg 

2CH 

36CH 

Char 

0 = Output 

T = Terminal 


1 

1 

I 

1 

t 

r 

Real 

6CH 

72CH 

Bin 

1 I/O r Input/Output 

1 

t 

A = Calling Argument 
C - Common 
F = Disk File 


SAM = Syatea Available Memory 



LTBSG 


IF USERID 
HISSING 


CALL DOSEG TO OBTAIN DOCUMENT 
AND SEGMENT IDENTIFIERS AND CODES 


PROMPT 
"USE DDT?" 



PROMPT FOR 
USERID 



Figure 7. 5. 3-1.- LTBSG functional logic fl 
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7.5.4 Program Name - Main Program LMXLG 


7. 5. 4.1 Purpose 

The sole purpose of LNXLO is to call subroutine LTXIO and to return to LTBU), 
LTXIO is used by both LTBLD and DOG. However, the main program of a segment 
must contain the name of the master segment that oalled it . Therefore , to 
avoid duplicating LTXIG with that single difference, LNXLG was written to 
call LTXIG and return to LTBLD, A similar routine exists for DOC, 

There are no inputs, no outputs, no internal variables, and no program logic. 


7. 5. 4. 2 Functional Description 
None. 

7.5. 4. 3 Assumptions and Limitations 
None , 

7. 5.4. 4 Method 
None. 

7. 5. 4. 5 Routine Input/Output Variables 
None , 

7. 5. 4. 6 Functional Logic Flow 

The functional logic flow for LNXLG is presented in figure 7. 5. 4-1, 


7.5. 4.7 Diagnostics and Debug 
None . 

7.5. 4. 8 Special Comments 
None . 

7. 5. 4. 9 References 
None , 
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CALL LTXIG (ENTRY ROUTINE 
INTO LINKAGE TABLE EDITOR) 


C RETURN TO A 
LTBLD j 
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Figure 7. 5. 4-1.- LNXLG functional logic flow. 
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8,0 JXig.M.TA13;flW..PiiPC£a3Q,aJli.QgJ. 


8.1 PURPOSE 

The purpose of the documentation processor Is to minimize mission planning doou- 
suntatlon time and oost through the semiautomated produotion of standardized 
documents. Mission planning data from the AWA are combined with blank forms 
from the Daoonlos to form segments of the desired dooument. These segments are 
then oomblned with the required plots and figures to produce the complete 
document . 


8.2 FUNCTIONAL DESCRIPTION 

The operation of the DOC is divided into three distinct functions. These are 
linkage table editing, file management, and dooument processing. The editing 
function allows the user to define data element names and values within the link- 
age tables. This function is performed by a copy of the standard FDS Interface 
Table Editor, 

The file management funotion consists of the cnnstruotlon of file names, the cre- 
ation, storage, retrieval, and purging of files, and the maintenance of file 
directories. The files that are used by the DOC are LINKAGE TABLE files, PROMPT 
files, FORM files, and DDT files, The FORM and DDT files reside on the Daconics 
system. In addition to these files, DIRECTORY files are maintained for document 
names, segment names, and LINKAGE TABLE and PROMPT file names. 

The actual document processing funotion consists of the following steps, The 
first "PAGE" of the blank form is moved into an Internal buffer. In this con- 
text, a page is defined to be that portion of a form that will fit in the buf- 
fer. The required data element values are then retrieved, either frem the AWA 
or the literal area of the LT. These values are converted and formatted accord- 
ing to the type and fonr;>.t specifications contained in the DDT, and are then 
merged into the reserveo spaces in the current page of the form. This process 
is repeated until the entire form haa been completed. The resulting document 
segment is then transmitted back to the Daconics for printing. 


8.3 ASSUMPTIONS AND LIMITATIONS 

a. All required data elements must either have beeh previously computed and 
plaoed into the AWA, or must have been input by the user into the litoral 
area of the linkage table. 

b. No units conversions are performed by DOC, with the single exception of 
time. 

0 . Variable-length tabular output is pe:v»ltted. However, the form must contain 
enough lirjes of blank spaces to accommodate the worst case, and there must be 
no data fields following a variable-length table within a segment. 
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d. The Daconios HP21MX oomputer must be up, and the connecting data channel 
must be active. 

e. The required Daconios files must be loaded on the working disk. 

f. There can be no more than separate data elements in the LT. However, any 
of the data elements may be dimensioned. 

g. The version numbers of the FORM, DDT, LT, and PROMPT files must all agree. 

h. The user cannot delete files fnom the Daconios system. 


8.4 PROCESSOR INPUT/OUTPUT 

a. Processor interface table - The FDS-1 version of the documentation processor 
does not use an interface table. All inputs are via user prompts. 

b. Interface table data file definitions - none. 

c. Processor solicited (prompted) inputs - The processor solicited inputs are 
provided in table 8.4-1, and are shown piotorially in figure 8.4-1. 

d. Processor displays and display parameter definition tables - DOC produces 
five displays and one tabular listing. All displays are optional, and are 
produced only upon request from the user. Three directory listings and 
three display parameter definitions are shown in table 8.4-II(a) through 
(f). These are the Document ID Directory (table 8.4-II(a)), Segment ID Di- 
rectory (table 8.4-II(c)), and the LT ID Directory (table 8.4-II(e)). The 
display parameter definitions table for the Document ID Directory are shown 
in table 8.4-II(b), the Segment ID Directory is shown in table 8, 4-11 (d), 
and the Linkage Table Directory is shown in table 8,4-Il(f). The other two 
displays are the blank form display and the merged segment display. These 
are identical in forroat, differing only by the presence or absence of the 
merged data. The remaining display is a listing of the data elements as 
they are retrieved and processed. 

The blank form display, merged segment display, and data element listing 
have no format inasmuch as their formats are determined by the material 
being processed , Examples of these displays are shown in the test report . 

e. Processor message table - Table 8.4-1II contains the proceSi'or messages that 
may be displayed for the user. Some indicate error conditions, and are 
followed by a user prompt to allow the user to take corrective action. 

Others simply inform the user as to the status of the procf.'s.s’ . The type 
of message is apparent from its content. 
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TABLE B.Jt-I.- PROCESSOR SOLICITED (PROMi=TED) INPUTS 
PROCESSOR DOC 



Promot. 

1 

1 

1 

Meaning 

1 

1 

1 . Valle resDonses^ 

ENTEH 

DOCUMENT ID 

r 

1 

1 

1 

1 

1 

* 

List directory 

1 

I 

I ? 

I Six- character document nama 

1 

1 

E?fTER 

SEGMENT ID 

1 

t 

1 

t 

1 

1 

t 

j 

List directory 

1 

1 

i ? 

1 Six-character segment name 

i 

_i _ 

ENTER 

SOURCE LINKAtS TABLE NAME 

1 

1 

t 

1 

l 

List Directory 

1 

1 

i ? 
1 



\ 

1 

1 

1 

Default LT 

1 

1 Space - carriage return 
1 



1 

1 

( 

1 

User default LT 

1 

r Space - user ID 
1 



( 

t 

1 

1 

User-owned LT 

1 

1 Four^character LT name 
1 

NOTE: 

Next prompt cornea from Linkage 
Table Editor. See section 8*0 
descripi-ion of prccipts and res- 
ponses * 

i 

1 

1 

fori 

1 

1 

1 

1 

1 

Nonuser-owned LT 

1 

1 Five-character LT name 
1 
1 
■ 

1 

1 

t 

1 

1 _ __ , - 

BUILD 

NEW LINKAGE TABLE? 

t 

( 

1 

1 

1 

Build new table 

\ 

i 

\ Yes 
1 



1 

1 

1 

1 

1 

Do not build 

1 

i No 
1 
t 

ENTER 

NEW UNKA<S TABLE NAME 

1 

t 

1 

1 

1 

List directory 

1 

1 

i ? 
1 



1 

t 

r 

t 

Create user default 

t 

1 Space - user ID 

t 



1 

i 

1 

1 

Create nondefault 

t 

\ Four- character LT name 

DO YOU WANT TO RECREATE THIS TABLE? 

1 

1 

1 

1 

1 

1 

t 

r 

1 

1 

1 

Delete existing 
table and replace it 
with -aw one with 
same name. 

1 

1 Yes 
1 
1 
1 
t 
X 
1 
1 



1 

1 

1 

1 

1 

1 

1 

i 

t 

r 

I 

Discard LT mods and 
terminate run 

t 

i No 
1 
( 
i 
1 
1 
1 
1 
1 
1 
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TABLE 8.4-1.- Continued 


1 




PROCESSOR 

DOC 


PrOTDt. 


1 

1 

\ . Meaning 

1 

1 

\ _ Valid responses 


DISPLAY BUNK FORM? 


t 

t 

! Display 
1 

i 

1 

; Yes 

t 




t 

i No display 
1 

r 

1 Ho 
1 

1 . 


ENTER HARDCOPY UNIT NUMBER, 

IF I^SIRED 

1 

j 

1 Display at terminal 

i 

1 

1 

r Space - carriage return 

1 




1 

i Print form on 

t 

( Unit number 




t specified unit 

1 

p 

1 

1 

1 


DISPLAY DATA ELEMENTS? 


j 

1 

! List data element 

» 

I 

1 Yes 




1 names, formats, raw 

t 

1 




[ values, and converted. 

! 



[ values as they are 

1 

1 




I processed 

1 

i 

I 

1 




r 

, Do not list 
1 
p 

i No 

1 


ENTER HARDCOPY UNIT NUMBER, 

JF DESIRED 

1 

1 

t Display at terminal 
1 

1 

1 

r Space - carriage return 
1 




\ 

i List data on 

t 

1 Unit number 




I specified unit 

1 

4 

1 

\ 

1 

__i _ _ 


DISPUY MERGED SEGMENT 


1 

1 

{ Display 
1 

1 

1 Yes 
1 




1 

i Do not display 

t 

t 

r 

] No 

t 

1 . . 


EJITER HARDCOPY UNIT NUMBER, 

I? DESIRED 

1 

1 

1 Display at terminal 

1 

1 

1 

i space - carriage return 
1 




t 

1 Print segment on 

r 

1 Unit number 


i 


1 specified unit 
1 
1 

1 

1 

1 

t _ _ _ - 


se:;d segment to dacohics? 


1 

1 

i Create output file 

t 

\ Yes 




1 cn Daconlcs 
1 

1 

1 

i 




r 

5 Terminate run 

1 

t 

t 

\ 

1 

1 

1 

t - 

\ No 

1 

t 

I 

r 

1 

1 

1 

J - — - — — 
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TABLS 8.11-1.- Concluded 
PROCESSOR DOC _ 


03 

I 

an 


FrCfflfit 


.MsaaJljag. 


:Valid gesixjases. 


ENTER FOUR-CHARACTER FILE IDENTIFIER 
IF DESIRED 


Use default name 


Space - carriage return 


Append identifier 
onto default name 


Unique identifier (may be one through four characters) 


WOULD you LIKE TO LOOK AT THE NEW 
DACONICS FILE? 


Recall segment from 
Daconics and display 
at tensinal 


yes 


Terminate run 


No 


NOTE: In response to any prempt, a user 

input of a will terminate 
the run. 



SYMBOLOGY 


- PROMPT 


INTERNAL 

DECISION 

POINT 




RESPONSE TO 
PROMPT 


■ ACTION TAKEN 
BY program 


NOTE; A RESPONSE OP n*' TO 

ANY PROMPT WILL TERMINATE 
THE PROGRAM. 


L 


J 



Figure 8.4-1.- Logic diagram of the DOC processor sollcitod inputs* 
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BLANK. 
USER ID 




^ USE DDT W 



YES y 

LIST DDT 3’»^~\yEr^ 


<i> 


1 


BLANK 



^ FOUR- A 
CimRACTER ) 
, IDEKTIFlEy 


USE USER'S COPY 


USE NAMED TABLE 


USE NAMED TABLE 


USE MASTER 

OF DEFAULT TABLE 


,N0T OWNED BY USER 


OWNED BY USER 


[ DEFAULT TABLE 


LIST DOT 

zr 
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Figure 8.4-1.- Continued 
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TABLE PROCESSOS DISPLAT FORMAT 


(a> Ooeument ID Directory 
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TABLE Coatlnued 
(c) Segment ID Directory 
PROCESSOR DOC 


-JflU 


JS_ 


_2D 25 22 35 SO iiS 52 55 _6 q 0 2iJ 

\ I \ \ I \ \ \ i \ isfEiGiHissNSTf ',t)ii\ntEicn\oiBix\ i s i 2 : s i : 2 s s ; 


1 I I f I I ) 
1 

Si s e g 


a a a a a a 
a a c a a Cl 
o a a a a Q 
a a a a a a 
a Q a a □ a 
o a e a a a 
a o B o a a 
a B a a o a 
ct a a a o a 
a B B a a B 


10 } 


15 i 


DOC 

a a a. a B a 
a a a a a a 
a a o a a a 
a a a B a a 
a a a a B a 
o a B a B a 
o Q a a B B 
B a a Q B o 
a Q B B B B 
O B Q B B B 


1 * D 

B B 
B B 
B O 
D B 
C B 
B B 

B a 

B B 

B a 
O B 


DESCRIPTION 


cBBaaaBaaBaBaaBaBaaBaBaBaBOBoaoaaBBOBBaB 

BaaBBBBaaBBaBBBBaaooaaoaBaeaBaaBBBaacaBa 

aaBOBBaBOBaaoBaoaaaooBBaaBBoaBOBBBBBaaoB 

BaaoBBoaBBBBBOBaaBaaaaBBaBaBaBBBOaBQaaaB 

oaBBBBQaBBBBaaaBaaoBOBBBBaaoBaaBBBoaaaBa 

BBaBBBaBBBBaaBBaBBBOaaaBaactBaaBBBOQBBBaa 

BBBaBBBBaBaBaaoaBasoaaactBBBBBBaaBBBaaaiCia 

BOBBaaoBoaBBaBBBBaaaaBOBaaaoQaBBaaaBBaaB 

BoaBBBaBBBBaBBBaaBBaBBttBaaatioaBBBoaBBBaa 

BBaBaoaBaaBOBBBaaaaaaaBBBBaaBoaaaaoaoBaa 


20 } 


2 * 1 } 


■ t —L. I U- 


1 I t 1 I I I 1 k 


10 


15 


20 


25 


30 


^35 




^5 


50 


55 


60 


j 1 i_ t 1 i-j-j. I 

65 70 
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TABLE 8.1J-II.- Continued 

Cd) Display parameter definitloa table for* the Segment ID Directory 
PROCESSOR tac 


1 

I 


1 


I 


- SEgHEWT^.I>,-gTS£g2QBl 

I 

I 

iMsplay \ 
parameter i 


■ -label ■ ! Eaggtteta-, figfinltipn 

1 

I 

SEG ! Slx-ctaracter segment identifier provided by segment designer. 

I 

I 

DOC 1 Six-character identifier of the document of lAlch this segment is a part. 

I 

1 

I.D. 1 Two-character identifier used Internally by DOC. 


DESCHimON 


Forty-character segaeit description. 


I 

} 


I 

I 

I 

1 

i 

! 
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TABLE Cent: -•* 

(e) Linkage Table Directory 






NAME DOC SEC DSV DESCRIPTION t 



D d Q a a a 
a a Q & o a 
Q a a a a a 
e o a Q a D 
o Q a a B o 
B B D a o B 
B a B B B a 
B a a a ct a 
a B a a B B 
B B B B B n 


B a a B a B 
B B B a a B 
B B B a B B 
o B a a a B 
B B B B B B 

a D a B B B 
a o a a B a 
B B B B B B 
B B O a B B 
a B B B B B 


B a a B B a 
B O B B B a 
B B a B Q a 
B a B B B B 

D a Q B a B 
B a a B a B 
a a a B Q B 
a D B a a B 

O B B B B B 
B B B B B B 


B B 

a B 
a a 
a a 

B B 

a B 

B B 
a B 

B B 

Q a 


a B 
a a 
a B 

B B 
B B 

a a 
B a 
Ct a 
B a 
B a 


X 

X 

X 

X 

X 

X 

X 

X 

X 

X 


QBBBBaaB 

BQaBBBaa 

aaBBoacB 

BBcaaBaa 

BBaBBaaB 

BBBBaaaB 

QBaaaaaa 

BcaaoBBa 

aaaaaflBB 

aaaaaaaa 


BBaBBaaB 

oBbaaBaa 

BBBaQBBB 

BBBBBBBa 

aaaBaBQB 

BOQBaaao 

B-BBaaBaa 

BBaBBaaB 

aoBaBBaa 

aoaaBBoa 


BBBBaaBa 
BBaBB BBa 
BraaBBCB 
aoaaoBBB 
aaBBoaDB 
BBaBBaaB 
OBOBBBaa 
BaaoBaBB 
BaanitaaB 
aaaaaaoa 


BaaBBOBB 

aQBBaaoa 

BBacBoaB 

aaaBBaao 

aaeaaaBO 

BBoaBBaa 

OBOaBBBB 

BoaBBaao 

BaaBBBBO 

OBBaaaBB 


BBaoBOBB 

BoaBBBOa 

BOSBOBBO 

BBaaBOBB 

aaBBBoaa 

oaBBBCoa 

aoQBaaoc 

BBaaaaaa 

BBaaBaoB 

aaBBaaBB 
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TABLE Concluded 

(X) Display parameter definition table for the Linkage Table Directory 


PBOCESSOR -- DOC. 


lIKRft5SJTAgi:£JSB£Cim. 


Display 

parameter 




Jargjgg^gr Pgliaitloji 


NAME 

DOC 

SEG 

D 

S 

V 

DESCRIPTION 


characters of LID|CA‘*E T^^LE file names and PROMPT file names. 
Six-character identif:^.er of document with idiich this file is associated* 
Six-character identifier of segment with idiich this file is associated. 
Two-character identifier of document with wiiich this file is associated. 
Two-character identifier of segment with which this file is asscclated* 
Version number 

Forty-character table description - 


1 

I 

I 

I 

I 

1 

I 

1 

I 

] 
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TABU) PBOCESSOR HBSSACS: TABLE 


PROCESSOR DOC. 


l" 

1 

J 

1 

1 

1 

1 

r 

MSG 

no* 

1 

1 

1 

1 

1 

1 

1 

Message 
ID block 

i 

1 i 

t Message text block and explanation i 

J _ .... . _ 

1 

I 

1 

t 

L 

1 

I 

t 

1 

.1 


! I 

IHVALID DOCOMEHT ID ! 

! . __ _ 

t 

1 

t 

I 

1 

2 

« 

r 

1 

t 

) 

1 


1 i 

1 INVALID SEGMENT ID ! 

i _ 

1 

] 

1 

L 

3 

A 

1 

t 

t 


! i 

; YOU HAVE REQUESTED SOMEONE ELSES DEFAULT TABLE. 1 

! ___ _ _ . . _ _ 1 

j 

It 

s 

1 

1 

I 

J. 


i i 

! UNABLE TO OPEN LINKAGE TABLE DIRECTORY. lERR = XX (FATAL ERROR) « 

{ . .. _ . . - ! 

j 

5 

t 

t 

t 

1 


i 1 

\ REQUESTED LT NAME NOT Bl DIRECTORY. 1 

1 , 


6 

i 

1 

1 

1 


1 S 

! REQUESTED LINKAGE TABLE IS NOT FOR REQUESTED DOCUMENT AND SEGMENT. 1 

1 _ _ _ _ 1 


7 

"l 

1 

( 

1 

1 


1 ! 
1 SEARCH FOR COMPATIBLE LINKA(£ TABLE ABANDONED (IN RESPONSE TO USER ABORT). i 

! 


8 

1 

1 

1 

1 

1 

t_ 


5 • i 
t LINKAH: table named XXXXXX already EXISTS. J 
• ! 


9 

1 

1 

1 

( 

1 

-t. 


; ! 
i MASTER DEFAULT TABLE MAY NOT BE RECREATED FROM DOC. ! 

^ ^ 1 


10 

1 

1 

1 

1 

1 

J 


! 1 
1 REQUESTED LT NAME DOES NOT PRESENTLY EXIST. 5 

! _ . - ! 


11 

1 

t 

1 

1 

i 

1 

1 

t 


I 1 

1 A LINKAGE TABLE NAMED XXXXXK ALREADl ^ 3 FOR ANOTHER DOCUMENT AND SEGMENT. YOU MOST SELFXTT S 

1 ANOTHER NAME. ! 

1 1 


12 

1 

1 

1 

1 

t 

1.. 


\ \ 

j YOU MAY NOT CREATE A TABLE WITH ANOTHER vSER'S ID J 

! { 


13 

i 

t 

i 

1 

1 

- 


i 

J DACONICS INPUT FILE NAME IS XXXXXXrXXXXXXiFORM ! 

i _ 1 


14 

1 

1 

1 

t 

t 

t 

1 

I— 


1 

i I/O ERROR IN DACIG. lERR = XX S 

1 % 

t > 

J ! 


8-17 


77F«18:V 


TABLE B.JJ-IU.- Concluded 
PROCESSOR DOC _ 


MSG 

no. 

t 1 

t 1 

i Message \ 

1 ID block 1 

1 1 

Message text block and explanation 



15 

1 1 

1 t 

1 1 

\ i 

i 1 

I t 

WRONG FORM. FORM IS FOR DOCUMENT XXXXXX, SEGMENT XXXXXX. YOU ARE CURRENTLY PROCESSING DXDKEWT 
XXXXXX, SGMENT XXXXXX. 



16 

f 1 

1 1 

! t 

1 1 

VERSION NBilEERS ARE INCOMPATIBLE. LIHKAtE TABLE VERSION 13 XX, FOIW VERSION NUMBER IS XX. 



17 

1 1 

1 1 

t 1 

t 1 

1 1 

I/O ERROR IN DOPRG. lERR = XX. 



18 

1 t 

1 t 

1 1 

1 1 

FORM CANNOT EE RETRIEVED. 



19 

1 1 

t 1 

\ 1 

t 1 

1 t 

DIMENSIONS MUST BE THE SAME WITHIN A TABLE. 



20 

1 1 

1 t 

1 1 

t 1 

1 \ 

MATRICES NOT PERMITTED WITHIN A TABLE. 


1 

21 

; i 

t 1 

t 1 

1 i 

i r 

1 i 

t 1 

1 1 

1 1 

1 1 

1 1 

! 1 

i ! 

1 1 

] i 

I ) 

1 1 

! 

t 1 

r t 

1 t 

1 1 

i i 

1 1 

! ! 

1 1 

! 1 

t S 

1 1 

1 1 

1 t 

t 1 

1 r 

1 1 

1 1 

1 1 

1 > 

! i 

1 t 

1 1 

1 1 

DACONICS SEGMENT FILE NAME IS XXXXXX. 

j 

1 
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8.5 DOCUMENTATION PROCESSOR (DOC) ROUTINES 

8.5.1 fip.utJLpfi- Jnograa-Pflg. 


8.5. 1.1 Purpose 

The purpose of DOC is to initialize various parameters in oommon, and to direct 
program flow through the program segments that are required for the completion 
of a document segment. It also monitors the status of the error flag upon re- 
turn from each segment ^ and terminates the session if it has been set. 


8.5, 1,2 Funotional Description 

DOC first sets the common variable PROPLG to 1 to inform those routines which 
are shared with LTBLD that they are being uc'’d by DOC, Four segments are c: 
by DOC; however, two of the segments are called more than once to perforr difj:e»- 
ent functions. The segment DPBSG is called first to process the document ,, .eg- 
ment, and linkage table requests. Segment LINDG is then called to retrieve the 
specified LINKAGE TABLE and PROMPT files to read the linkage table into common. 

Segment LNXDG is then called to activate the Linkage Table Editor, and to give 
the user the opportunity to make any desired modifications to the table before 
it is used by the processor. After the modificatJons (if any) have been 
completed, LINDG is called again to give the user ihe opportunity to create a 
new LINKAGE TABLE file, LTBSG is then called a second time to retrieve the ap- 
propriate FORM file from the Daconics, 

This completes the preparations for the actual document segment creation pro- 
cess. Segment DOPRG utilizes the LINKAGE TABLE, PROMPT file, and FORM file as 
inputs to produce a completed segment ready for transmission back to the 
Daconios, Since segment DPBSG contains the Daconics interface, it is called a 
third time to carry out that function. This completes that portion of the 
semiautomated documentation process that Is performed on the HP21MX. 


8.5. 1.3 Assumptions and Limitations 
None, 

8.5.1. it Method 
None. 

8,5. 1.5 Routine Input/Output Variables 

The DOC input/output variables are presented table 8.5. 1-1. 
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8.5. 1.6 Funotional Logic Flow 

The funotional logic flow for DOC is presented in figure 8.5, 1-1. 

8.5. 1.7 Diagnostics and Debug 
None . 

8.5. 1.8 Special Comments 
None . 

8.5. 1.9 References 
None. 
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TABLE IKPDT/OUTPUT VARIABLES 

Routine J)DC 


Code 


Math 


svmbol 1 symbol. 1 Tvoe 

1 

Ds 5_. I Units 1 SoiMe 

1 

External label. 

1 

Definition 

1 

1 

LU i 

1 

1 

1 Intg 

1 

t 

t 

1 

1 

1 

1 

I/O 1 

1 

t 

t 

1 c 
1 

1 ” 
1 
1 
1 
1 


1 

r 

t 

t 

1 

Logical unit of user*s terminal 

1 

r^ERiD ; 

1 

1 Intg 
1 

t 

1 

1 

1 

I/O ! 

I 

t 

! c 

i 

1 

1 

I 

1 


1 

1 

1 

1 

One-cbaracter user-ID 

\ 

KAMFRM ! 

1 

1 ecH 

t 

1 

( 

1 

\ 

1 

0 ; 
1 

f 

1 c 
1 

1 

1 

1 

1 


i 

1 

1 

1 

Name of FORM file 

1 

NOUTFL j 

1 

t 

i 6CH 
1 

1 

1 

1 

1 

( 

0 i 
1 

t 

t c 

1 

1 

1 

t 

1 


I 

1 

1 

1 

Name of output segment file 

ICR [ 

1 

i Intg 
1 

1 

1 

r 

1 

0 ! 
1 

1 

I c 

1 

1 

\ 

1 


( 

1 

1 

i 

Cartridge number - LT files 

1 

JSECU } 

1 

1 

1 2CR 
1 

1 

1 

1 

1 

0 \ 

1 

1 

i c 
1 

( 

r 

1 


1 

i 

I 

1 

Security code - LT files 

1 

JCR 1 

1 

i Intg 

\ 

1 

1 

1 

1 

1 

0 1 
1 

1 

i c 

t 

1 

1 

1 

1 


1 

1 

t 

1 

Cartridge number - directories 

1 

JSEQ i 

1 

1 2CH 

J 

1 

1 

1 

t 

r 

0 1 
1 

1 

1 c 
1 

1 

1 

1 

t 


1 

1 

i 

1 

Security code - directories 

i 

PROFLG I 

1 

1 Intg 
1 

t 

1 

1 

1 

1 

0 i 
1 

1 

1 0 

1 

1 

t 

t 

1 


1 

1 

1 

t 

Processor flag: 

1 

» 

t 

\ 

1 

1 

1 

1 

1 

1 

1 

1 

1 

1 

1 

1 

t 

1 

1 

1 

1 

1 

1 

1 

1 

1 

5 

t 

t 

t 

1 

1 

1 

1 

1 

1 


1 

4 

1 

t 

r 

\ 

0 = LTBLD 

1 = DOC 

r 

lOPTK [ 

1 

1 Intg 

t 

1 

1 

1 

\ 

t 

0 ! 

t 

1 

1 c 

1 

t 

1 

« 

1 


1 

1 

1 

1 

Option flag: 

j 

1 

1 

1 

1 

1 

1 

1 

r 

1 

1 

1 

1 

1 

1 

1 

1 

i 

t 

1 

i 

t 

t 

1 

1 

t 

1 

1 

1 

1 

1 

1 

t 

1 

1 

1 

1 

1 

1 

» 

1 

1 

1 

1 

t 

t 

r 

1 


1 

1 

r 

1 

\ 

1 

1 

1 

0 = Retrieve DDT 

1 s Retrieve form 

2 r: Send segment 

1 

isw ! 

1 Intg 

1 

1 

1 

1 

0 ! 

1 

! c 

1 

1 

1 


1 

Control fl^ for LTHAG: 


1 = First entry 
Z = Second entry 



1 

( 

TYPE 




1 


1 

1 


ROTES: 

1 

1 

Free 

DubI 

13cH 

Mix 

i I = 

Input 

I 

1 

IT = Interface Table 


1 

( 

Intg 

2CH 

36CH 

Char 

1 0 = 

Output 

1 

I 

T = Terminal 


1 

1 

1 

1 

Real 

6CH 

72CH 

Bln 

1 I/O 

1 

t 

= Input/Output 

1 

I 

1 

1 

A = Calling ArgUBent 
C = Common 


F = Disk File 

SAH = System Available Hssory 




Page 1 of 1 

Figure 8. 5. 1-1.- DOC functional logic flow. 
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8.5.2 gabnoutAng-Jlarae-r-JiLHAfi 


8. 5. 2.1 Purpose 

The purpose of' this subroutine is to retrieve values from named data elements in 
the AWA. 


8. 5. 2. 2 Functional Desorlption 

AWAG used the FDS utility XPGBT to access data values in the AWA. A special 
initialization call to XPGET is executed on (and only on) the initial entry into 
AWAG. 

AWAG operates either in "TABLE" mode or "NORMAL" mode. If the data ele ment to 
be retrieved is dimensioned, and is one of a set of data elements whose values 
are to be displayed in column tabular format, then special processing is 
required, To illustrate, suppo.se two arrays, A and B, are each dimensioned 
by 10, and are to be displayed as two side-by-side columns; A in column 1 
and B in column 2. "Since the output fron the dooumentation processor must 

be produced line-by-line, the values must be retrieved in the order A(1), 

B(1), A(2), B(2), However, if the values of a dimensioned array are 

to be displayed in the order in which they are stored, all of the values 
will be retrieved with a single call to XPGET, 

XPGET is designed to access data elements that appear in an interface cable 

which is created and cataloged by the FDS Executive, 

Since the data elements to be retrieved by AWAG are described in an LT, which is 
unknown to the FDS Executive, an intermediate step must be gone through before 
XPGET is caus'd. The documentation processor has associated with it an 
interface table that contains a single dummy parameter. Upon each entry to 
AWAG, the dummy parameter is replaced with the desired entry from the LT. XPGET 
can then access the AWA exactly as it would if a normal interface table was 
being used . 

When operating in "TABLE" mode, the information in the LT must be modified 
before placing it in the interface table. If the LT information was to be used 
directly, XPGET would retrieve all the values on the first call. To prevent 
this, and to ensure that the correct value is retrieved on each call, the FDS 
utility XPATR is called once for each parameter that is included in the tabular 
output, XPATR returns a pointer to the first value in the array. AWAG uses 
this pointer to address the first value to be retrieved. The data type is used 
to compute the length of the value in words, and for each subsequent call the 
pointer is Incremented by the value length to compute the next address. In this 
way, AWAG is able to retrieve all of the values to be included in the tabular 
output one at a time in the order in which they are to appear . 
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6, 5. 2. 3 Assumptions and Limitations 

AWAO assumes that It la being executed under the PDS Executive, and that the FDS 
utility XPGET is available, 

8.5,2.*» Method 
None, 


8.5. 2.5 Routine Xnput/Output Variables 

The AWAO input/ output variables are presented in table 8. 5, 2-1. 

8. 5. 2.6 Functional Logie Plow 

The functional logic flow for AWAO is presented in figure 8. 5. 2-1. 

8. 5. 2. 7 Diagnostics and Debug 
None, 

8. 5. 2.8 Special Comments 
None. 

8. 5. 2.9 References 
Hone . 
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TABLE 8.5.2'-! “ INPUT/OUTPUT VARIABLES 
Routine AJiAfi 


Code 

1 ) 

1 1 

1 Math ! 


1 

) 

t 

r 

1 

1 

1 

1 

symbol _ 

j .aymbol , ] 
1 1 

.J.YPS- 

- i i ^o.ur,ge 

1 1 

lAERAY 

1 1 

1 \ 

1 1 

( 1 

Intg 

r 

I 1 

f 

1 

1 A 
1 

IDEEUG 

1 1 
1 1 
1 1 
1 1 

Intg 

I I 
1 

1 

1 A 

X 

ITYPE 

r 1 

■ 1 

t j 

1 1 

Intg 

r 

X 1 

1 

1 

! A 

t 

lUKIT 

X t 

I 1 

1 1 

i 1 

Intg 

1 

X 1 
1 

1 A 
1 

LENS 

1 1 

1 \ 

1 J 

% t 

Intg 

J 

I 1 

1 

1 

1 A 
1 

LINE 

1 1 

1 1 

i 1 

i 1 

Intg 

J 

I s 

1 

i A 
1 

LNSTRT 

1 t 

1 i 

I 1 

1 X 

Intg 

1 

I [ 
1 
t 

i 

i A 

1 

1 

TABLE 

\ 1 

1 1 

1 t 

t r 

I 1 

Intg 

1 

1 

I [ 

1 

1 

1 

! A 
1 

LU 

t 1 

1 1 

1 r 

1 1 

Intg 

1 

I i 

J 

1 

1 C 

1 

LITPTR 

1 1 

1 1 

1 t 

1 1 

Intg 

I 

I 1 
1 

1 

1 c 
1 

HEDR 

1 1 

1 ! 

! 1 

Intg 
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Figure 8, 5. 2-1.- AMAG functional logic flow. 
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8,5.3 

6, 5. 3.1 Purpose 

The purpose of this subroutine is to unpack an array, which is in AR format, 
into an array in R1 format. 


8, 5. 3. 2 Functional Description 

BRUPK differs frcra the similar IBM utility XBUPK in two wayt3. First, It does 
not suppress blanks, allowing data to be right- justified in a field, Second, it 
has the option to replace blanks with zeros. This permits the presentation of 
time in the desired format. For example, a time of 1 day, 7 hours, 4 minutes, 
and 23,85 seconds would appear as 1 :7 :4 t23>65 using XRUPK, while using BRUPK 
will allow the time to be shown as 01:07:04:23,65. 


8. 5. 3, 3 Assumptions and Limitations 

The calling program must have dimensioned IXX by at least IRETC, 


8. 5. 3. 4 Method 
None . 

8. 5. 3.5 Routine Input/Output Variables 

The BRUPK input/output variables are presented in table 8, 5, 3-1. 


8, 5, 3.6 Functional Logic Flow 

The functional logic flow for BRUPK is presented in figure 8. 5. 3-1. 


8. 5. 3.7 Diagostios and Debug 
None . 

8. 5. 3.8 Special Comments 
None . 

8. 5. 3.9 References 
None , 
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TABLE 8.5-3--I*- DtPDT/OtPTPUX VARIABLES 
Routine BRUPK 
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Figure 8. 5. 3-1. - BRUPK functional logic flow. 
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8,5. M Subroutine. DACIG 


6,5.4.! Purpose 

The purpose of subroutine DACIO is to manage the transfer of data between 
HP2fMX data elements and Oaoonios files, Por the LTBLD, PACIG retrieves DOT’S 
from Daconios and places them on the data element ^DDTG on the 

HP2iMX, For the documentation processor, It transfers blank fow"" from the 
Daconios to $FOFIMG on the HP21MX, and '-rsnsfers completed segmeiUij from $OFRMG 
on the KP21MX to the Daconios. 


8,5. 4. 2 Functional Description 

DACIG first determines what function it is expeottii to perform. If a file is to 
b'.' retrieved from the Daconios, the file name is constructed in the form 
DOCNAM:SEQNAM:XXXX where XXXX is either DDT or FORM, depending on which is to be 
received . The name of the destination data element is then stored , the name 
ueing deterained by the type of file to be retrieved. 

The header record is read from the Daconios file, and the version number is 
extracted. If it ii a DPT, the version number is stored, and the header is 

written to the HP21MX file. If it is a FORM, the version number is compared 

with the version number of the current LT, and the run is aborted if they are 
different. If the version number is correct (or it is a DDT), the remaining re- 
cords are transferred and control is returned to the calling program. 

If a completed segment is to be sent to the Daoonios, the program tij'-st solicits 
confirmation frcra the user that the segpient is actually to be sent. If it is, 
the user is given the opportunity to supply a four- character identifier to be 
appended onto the basic file name. The segment is then sent to the Daconios 

via a call to DWRIT. After the segment has been sent, the user is given the op- 

portunity to recall it for display at his terminal. This provides a mechanism 
for the user to verify the transmission before terminating the run. 


8. 5. 4. 3 Assumptions and Limitations 
None . 

8. 5. 4.4 Method 
None . 

8. 5. 4.5 Routine Input/Output Variables 

The DACIG input/output variables are presented in table 3,5. 


8-29 



77FM18:V 


8. 5. ^.6 Punnfcional Logic Flow 

The functional logic flow for DACIO is presented in figure 8,5. *1-1. 

8.5. *(.7 Diagnostics and Debug 
None. 

8.5. *1.8 Special Comments 
None. 

8. 5. **.9 References 
Hone . 
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TABLE ISPtlT/OtrePIJT VABIABLES 

Routine DACIG 
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Figure 8. 5, 4-1*“ DACIG functionM logic flow* 
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8.5.5 SubrPUtlRe. WPfltL 


8. 5. 5.1 Purpose 

The purpose of this subroutine Is to retrieve the specified data elements, 
reformat them, and merge them with the blank fora t>o produce a ccmplete document 
segment . 


8, 5. 5. 2 Functional Description 

DQPHG first checks bo see If the form has been retrieved from the Daoonlcs. If 
the form has not been retrieved, the user is given the option to continue 
processing, and display the data values at the terminal, or to abort the run. 

If the form has been retrieved, or if processing Is to continue without It, the 
parameter names, table flags, and format specifications are retrieved from 
the PROMPT file. 

The first "PAGE" of -the form Is then read into the internal working buffer and 
prepared for processing. A p; s of the fora is defined as that portion which 
will fit In the buffer. The segment is processed page-by-pcge until the seg> 
ment is ccmplete. 

The actual processing is done In either of two modes; l.e., RMAI,. mode or TABLE 
mode. The "TABLE FLAG," obtained from the DDT (via the PROMPT file), indicates 
those parameters that are to be processed in TABLE mode. Ii'k NORMAL mode, the pa- 
raneters are processed in the order In which they appear in the LT. All values 
of a dimensioned array are retrieved as a group. However, in TABLE mode, those 
arrays that are to be presented in tabular format are retrieved one value at a 
time. For example, if two arrays (dimensioned by 10 each} are to be displayed 
in two parallel columns of a table, DOPRG processes the first value of the first 
array, the first value of the second array, the second value of the first array, 
etc., down through the tenth value of each array. 

Upon entry into TABLE mode, the LT is searched for the end-of-table flag, and 
the beginning and ending parameter numbers (within the LT) are stored. The di- 
mensions of all parameters to be included within the table are checked for oon- 
siatency, and a check Is also made for any BUltidimen.<iioried arrays. If every- 
thing is proper, a pair of nested DO-LOOPS is initialized; the outer DO-LOOP 
steps through the number of lines to be displayed in the table, and the inner 
DO-LOOP steps through the number of parameters (or columns) in the table. If 
not in TABLE mode, the initial and final values of the inner DO-LOOP are set to 
the same value so that the parameters in the LT will be processed in order, with 
no looping. 

For each parameter, the LT is examined to determine if it contains a value 
or a data element name, If a name is present, the PDS utility is called 
to obtain the valus(s) fTom the AWA. Otherwise, the value(s) is/are obtained 
directly from the literal area of the LT. 
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The format speolfioation for the current parameter is then analyzed to determine 
the conversion required. If it is a "T“ format, the specification is subjected 
to a lexical scan, and the resulting formats are constructed. 

The next step is the conversion and reformatting of the value(s) fron their orig- 
inal form into the form specified by the DDT. To accomplish this, the raw value 
is placed into an Integer Input array. This array is equivalenced to a real 
array and a double-precision array. If the value is a character string, it is 
simply moved into the output array. Otherwise, a oore-to-core write is 
performed using the Fortran CODE function to perform the conversion. CODE is 
called with the input array name that corresponds to the data type (e.g., the in- 
teger array name is used if the data type is integer). The format used for the 
core-to^oore write is the one constructed in the previous step. In this way, a 
real number can be converted to an ASCII "I'> format, an *'F" format, a "T” for- 
mat, or a "D” format. Similarly, integers and double-precision numbers can be 
expressed in any specified format. 

After the conversion and reformatting has been performed, subroutine MERG is 
called to place the value in the next available reserved space in the blank 
form. If it is a "T" format, MERG is called for each field in the format speci- 
fication. 

The above process is repeated until all parameters in the LT have been 
processed , Subroutine SOUTG is then called to transfer the last page of the 
completed segment to the output data element where it will await transmission to 
the Daconica. Subroutine SDISG is called to give the user the option to display 
the ccmpleted segment at his terminal. (These last two steps are omitted if the 
form switch is turned off.) 


8. 5. 5. 3 Assumptions and Limitations 
None. 

8. 5. 5. if Method 
None . 

8. 5.5.5 Routine Input/Output Variables 

The DOPRG input/output variables are presented in table 8, 5. 5-1. 

8. 5. 5.6 Functional Logio Plow 

The functionel logic flow for DOPRG is presented in figure 8, 5. 5-1. 
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8, 5. 5.7 Diagnostics and Debug 
None . 

8. 5. 5, 6 Special Comments 
None. 

8, 5. 5. 9 References 
None. 
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TABI£ 8,5.5-!.“ DIPaT/OtirPBT VAHIABLES 
Routine DOPRG 
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Figure 8,5.S-1.- DQPRG functional logic flow. 
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8,5.6 Snbroutj.no., ■DO^EO, 


8,5.6, 1 Purpose 

Subroutine IX)SEG obtains the doouinenb and segment Identifiers from the user, and 
checks their validity against the document and segment directories, If they are 
valid, the associated two-character codes are retrieved from the directories, 
and the Identifiers and codes are placed In common. If either Is invalid, the 
user Is given the opportunity to update the directory if a new segment Is being 
added to the system, or to correct his input If an error was made. 


8. 5. 6. 2 Functional Description 

The user is prompted for the document ID, This is the six-oharaoter Identifier 
by which a document Is known to the system. Possible responses are a to 
terminate the run, a "7” to list the directory, an invalid ID, or a valid ID. If 
an ID is input that does not exist in the directory, the routine determines 
whether it is being called by LTBLD or by DOC, If it is called by DOC, a diag- 
nostic is sent to 'the terminal and the user is reprompted. If called by LTBLD, 
the user is notified that the ID does not exist, and asks if the ID is to be 
added to the directory. If not, the user is reprompted. If it is to be added, 
the user is prompted for the two-character code to be assigned to the new entry, 
and for a description that aooorapanies the new entry in the directory. 

When this process is completed for the document ID, an Identical process is 
gone through for the segment ID, with one exception. If the requested document 
ID appears in the directory, it is valid. However, even if a segment ID appears 
in the directory, it must be for the correct document or it is considered In- 
valid , 


8.5.6. 3 Assumptions and Limitations 

Assumes that the two required directories are available on the HP21MX mass 
storage system. 

8. 5. 6. 4 Method 
None. 


8. 5. 6. 5 Routine Input/Output Variables 

The DOSEG input/ output variables are presented In table 8. 5.6-1. 


8. 5. 6. 6 Functional Logic Flow 

The functional logic flow for DOSEG is presented in figure 8. 5. 6-1. 
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8, 5. 6.7 Diagnostics and Debug 

Subroutine DOSelD contains two sets of dlagriost^oc. One set is usad if 
DOSEG in being used by DOC; the other is used If DOSEG is being used by 
LTBLD. 


DOC Diagnostics 


Diagnostic 

Meaning 

Action 

Invalid document ID 

Requested document 
ID does not exist 
in directory. 

Reprcmpt 

Invalid segment ID 

Requested segment 
ID does appear in 
directory ,for, this 
document. 

Reprcmpt 

LTBLD Diagnostics 

Diagnostic 

Meaning 

Action 

Requested document 
ID does not presently 
exist • 

Sel f- explanatory 

Ask user if he 
is adding new 
document to 
system. 

Requested code already 
exists. 

Requested two-char- 
acter code has al- 
ready been assigned. 

ReprtMupt , 

Requested segment ID 
does not exist for 
this document. 

Requested segment ID 
either does not 
exist, or is for 
another document. 

Ask user if he 
is adding new 
segment . 

Requested code already 
exists for this document 

Self-explanatory. 

Reprompt , 
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8, 5.6.6 Special Comnienta 
None . 

8, 5. 6, 9 Hoferonoes 
None, 
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TABLE 8 , 5 . 6 -!*- IHPUT/OUTPUT VARIABLES 
Routine pOSSG 


Code 
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1 

1 

1 

1 

1 
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1 

t 

1 

1 

Tvoe 

1 

1 

1 
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I 
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1 

X 

X 
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\ 
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X 

1 

1 

_ Definition _ 

I 

DOCID 

1 

t 

% 

i 

t 


1 

1 

1 

1 

1 

2CH 

1 

1 

1 

1 

j 

1 

t 

0 1 
1 

1 

t 

5 C 

1 

t 

1 

1 

1 

1 


1 

1 

* 

1 

1 

Twc>-character document code 


DOCHAK 

1 

1 

r 

1 


1 

1 

1 

6CH 

i 

t 

1 

r 

I/O 1 

1 

1 x,c 
1 

i 

1 

1 

1 


» 

! 

1 

Six-character docuaiCnt riaae 


JCR 

( 

1 

1 

I 

1 

t 


1 

1 

r 

t 

Intg 

1 

1 

1 

1 

I i 
1 

1 

1 c 
\ 

f 

1 

t 

X 


1 

1 

1 

I 

Cartridge containing diractories 


JSEQ 


1 

1 

1 

2CH 

1 

1 

1 

) 

X 1 
1 

i 

1 c 
1 

1 

1 

1 


1 

1 

1 

1 

Security code for directories 


LU 

1 

i 

\ 

1 


1 

1 

1 

1 

Intg 

1 

i 

1 

1 

t 

1 i 
1 

( 

i c 
1 

1 

1 

1 

t 


t 

1 

I 

1 

User terminal logical unit 


PROFLG 

1 

1 

1 

) 


1 

1 

1 

1 

Intg 

} 

i 

t 

t 

1 

I 1 

1 

1 

J c 

1 

1 

1 

1 

t 


1 

1 

t 

1 

Processor flag 



1 

t 

! 


I 

1 

1 

f 

1 


1 

1 

1 

1 

1 

1 

i 

T 

1 

t 

1 

} 

1 

1 

1 

t 

i 

1 

1 

1 

1 


1 

1 

1 

1 

1 

t 

0 = LTBLD 

1 DOC 


SEGID 

I 

1 

r 

i 


1 

1 

( 

1 

2CH 

t 

t 

T 

1 

1 

0 i 
1 

1 

1 c 
1 

X 

X 

1 

1 


1 

1 

1 

X 

Two-character se^aent ID 


SEGNAM 

1 

1 


( 

1 

r 

6CH 

1 

t 

1 

1 

I/O } 

1 T,c 

1 

1 

1 


t 

\ 

t 

Six-character accent name 



NOTES: 


TYPE 




\ S 2 Si 


1 

1 

som^ 

Free 

Dubl 

IBCH 

Mix 

} I = 

Input 

1 

1 

IT = Interface Table 

Intg 

2 CH 

36 CH 

Char 

i 0 = 

Output 

1 

X 

T = terminal 

Heal 

6 CH 

72 CH 

Bln 

1 I/O 

= Input/Output 

t 

t 

1 

I 

A = Calling Argument 
C A Cottmon 


F - Dialc File 

SAH System ATallable Memory 




PROMPT FOR 
DESCRIPTION OF 
NEW DOCUMENT 


IF CODE 
ALREADY, 
EXISTS 


PRINT "REqUESTED 
CODE ALREADY EXISTS, 

YOU MUST SELECT ANOTHER 
CODE" 


Figure 8.5. 6-1.- DOSES functional logic flow. 
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6,5.7 jjautiJis-Namg-r- MaAii-Pr.ofiiaiii-It£Bfig. 


8.5,7. 1 Purpose 

The purpose of DPBSG is to process the user requests for the document and seg- 
ment to be processed » and the linkage table to be used, The reason these func- 
tions are performed In this small segment Is to make more room for working 
buffers in segment DOPRG, the main document processing segment. The Interface 
to the Daoonlos data channel is also in this segment for the same reason. 


8, 5,7.2 Functional Description 

Processing within DPBSG is controlled by an option flag that directs the flow of 
execution to different parts of the program, Segnient DPBSG is called three 

times during a normal documentation session. For the first call, the option 
flag is set to zero, and subroutines DOSBG and LTNMG are called to process the 
document, segment, and linkage table names. 

For the second call, -the flag has a value of 1, and subroutine DACIG is called 
to retrieve the appropriate blank form fV’om the Daconios, 

For the third call, the flag has a value of 2, and DACIG is called again to send 
the completed segment back to the Daconies, 


8. 5. 7. 3 Assumptions and Limitations 
None . 


8.5.7,^ Method 
None , 


8. 5. 7. 5 Routine Input/Output Variables 

The DPBSG input/cLiput variables are presented In table 8, 5. 7-1. 

8. 5. 7. 6 Functional Logic Flow 

The functional logic flow for DPBSG is presented in figure 8. 5. 7-1. 

8. 5.7.7 Diagnostics and Debug 
None . 
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8. 5. 7. 8 Special Comments 
None, 

8. 5. 7. 9 References 
None. 
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TABLE 8. 5. 7-1.- IHFUT/OUTPUT VARIABLES 
Routine DPBSG 


Code 

. ,syffl]agJL. 

lOPTN 

LTNAM 

NLTNAH 

XEd) 


Math 

■aymbol_ 


-lygg. 

Intg 

6CH 

6CH 

Intg 


■ 

I 

0 

0 

I/O 


■Unitg 


c 

c 

c 

c 



1 TYPE 





gomes 

NOTES: 

1 Free 

Dubl 

leCH 

Mix 

I = Input 

IT = Interface Table 


i Intg 

2CH 

36CH 

Char 

0 = Output 

T = Terminal 


1 Real 

i 

1 

1 

1 

1 

1 

■ J 

6CH 

72CH 

Bin 

1 

I/O - Input/Output 

A - Calling Argument 
1 C = Common 
F - Disk File 

! SAM = System Available Memory 


External label. 


_ Definition 


Option control fOag 
Input linkage table name 
Output linkage table naBG 
Error flag 
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Figure 8. 5. 7-1.- DPBSG functional logic flow. 
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8 . 5.8 


8.5.8, T Purpose 

The purpose of this subroutine is to retrieve a record Oi" data from the Daoonica 
via the data ohannel, and to perfonn a charaober set transformation to convert 
the Daconios special oharaoters into oharaoters acceptable to the HP21MX. 


8.5. 8. 2 Functional Description 

DREAD first makes an EXEC call to retrieve a block of data from the Daconios, 

The amount of data to be retrieved is specified by the input parameter "LENGTH." 
After control has beer returned from the EXEC call, a second EXEC call is made 
to obtain the ocmpletion status of t';e first call. If a nonzero status was 
returned, the status value is placed in the outpi't parameter "ISTAT," and con- 
trol is returned to the railing program, 

If the read was successful , the received data are either returned to the calling 
program as is, or are processed as i'cllows! 

The record is first checked for nrntero values. If the record contains all 
zeros, the record is discarded and the next record is read. If the record con- 
tains nonzero data, the Di.ooni'.ae 4;;*. ial characters are converted to standard 
HP21MX characters, and thr litngth of the record is placed in the output parame- 
ter "LEN." 


8. 5. 8.3 Assumptions and Limitations 
None . 

8.5.8.11 Method 
None , 

8. 5. 8.5 Routine Input/Output Variables 

The DREAD input/ output variables are fresented in table 8. 5. 8-1. 

8. 5. 8. 6 Functional Logic Flow 

The functional logic flow for DREAD is presented in figure 8. 5*8-1. 

8. 5. 8.7 Diagnostics and Debug 
None. 
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8, 5. 8,8 Special Cotnirtenbs 
Kone. 
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8,5.8, 9 References 
None, 
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TABLE 8.5.8-!.- INPUT/OUTPOT VARIABLES 
Routine DREAD 


i ! 

Code 
■ jaynbol. 

I ARRAY 

IICOH 


ISTAT 

LBN 

LENGTH 


Math 

J&CGbsL. 


,lygg. 

Intg 

Intg 

Intg 


1 


Intg i 

1 

Intg I 

t 

I 

i 

I 


0 

I 


UMts 


A 

A 


S£WrnaI label 




Array contatning data record 
Data conversion flag 
0 = no conversion 
Error status 
0 = DO error 

Length of data record read 

Length of data block to be read 
(64 or 128 words) 


NOTES; 


2XEK 
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Figure 8,5.8-!.- DREAD functional logic flow. 
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6.5.9 Subroutine DWRIT 


8, 5. 9.1 Purpose 

The purpose of this subroutine is to send a record of data to the Daoonics via 
the data channel . 


8. 5. 9.2 Functional Description 

The input parameter "LENGTH" is first tested for valid input. If "LENGTH" is 
zero, the error status flag is set, and control is returned to the calling pro- 
gram, The input parameter "ICON" is then tested to see if a character set con- 
version is required. If ICON is zero, the re cord is transmitted as is. If 
ICON is nonzero, t.ll spaces are converted to nulls, and hyphens (and minus 
signs) are converted to either "REQUIRED HTPHEN, END OF LINE," or "REQUIRED HY- 
PHEN, NOT END OF LINE," as appropriate, The modified record is then transmitted. 


8. 5. 9. 3 Assumptions and Limitations 
None , 

8.6.9. 4 Method 
None . 

8. 5. 9. 5 Routine Input/Output Variables 

The DWRIT input/output variables are presented in table 8, 5. 9-1. 


8, 5 -9. 6 Functional Logic Flow 

The functional logic flow for DWRIT is presented in figure 8. 5,9-1. 


8. 5. 9. 7 Diagnostics and Debug 
None . 

8. 5. 9. 8 Special Comments 
None . 
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8. 5. 9. 9 fleferenoea 
None. 
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7rrrtiy:Y 


lARRAY 

ICON 


LEN 

LENGTH 


Math 

°vmbo]I 


T-VPe 

Intg 

Intg 


TABLE 3.5.9-!.- INPUT/OUTPUT VARIABLES 
Routine DWRIT 
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TYPE 
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Mix 
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1 
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1 

1 
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36CH 

Char 

1 0 =: Output 

1 

1 

T = Terminal 
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1 

1 

Real 

6CH 

72CH 

Bin 

1 I/O = Input/Output 

t 
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1 

1 

A = Calling Argument 
C = CoiEmon 


Array to be transmitted 
Character conversion flag 
0 = no conversion 
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0 no error 

Kiznber of words of data in lARRAT 

Length of record to be transaltted 
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F = Disk File 
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Figure 8. 5. 9-1.- DWRIT functional logic flow. 
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8 . 5.10 


8,5.10,1 Purpose 

The purpose of this subroutine is to page the blank form into the internal 
working buffer. In general, doouraent segments will be larger than the available 
buffer space. It is therefore necessary to read and process the form in a se- 
ries of portions that do not exceed the buffer size. 


8,5.10.2 Functional Description 

The length of the available buffer is given by the input argument JPMAX. Suooes- 
sivG records are read from the file named $FORMO until the current record will 
not fit. The current record number is saved, and the total number of characters 
that were stored are placed into the output argument IBPNTR. On subsequent 
ontries, the reading from $F0RMG begins with the record number that was saved 
frcin the previous entry, and the process is repeated until $F0RMG is exhausted . 
After the last record is placed into the buffer, a value of 777 octal is stored 
to indicate end-of-data. As the data are read and stored, they are converted 
from A2 format into R1 format. 


8,5.10.3 Assumptions and Limitations 

The form to be processed must reside on the file named $FORMG, 

The buffer length indicated by the input argument JPMAX must not exceed the di- 
mension of the buffer. 

8.5.10.^ Method 
Nona , 


8.5.10.5 Routine Input/Output Variables 

The FMING input/output variables are presented in table 8,5,10-1. 

8.5.10.6 Functional Logic Flow 

The functional logic flow for FMING is presented in figure 8.5.10-1. 

8.5.10.7 Diagnostics and Debug 
None. 
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8.5.10.8 Special Comments 
None . 

8.5.10.9 Heferenoea 
None . 
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TABIZ 8.5.10-1*- IHPUT/OirrPUT VARIABLES 
Routine _ , 


1 _.£vmbol 1 symbol { Type 

t f 

1 FORBOF f 

1 1 

1 

i Intg 
1 

1 t 

J IBPNTR i 

1 t 

1 1 

1 Intg 
1 
1 

t r 

( 1 

1 IDCB j 

t t 

1 

t 

1 Intg 

t 

1 1 

i lERR 1 

1 t 

I Intg 

i 

j 1 

1 JCR i 

1 } 

1 Intg 

» 

t 

1 JPMAX 1 

X l 

i Intg 
1 

\ 1 

j LLENTH \ 

1 1 

1 1 

i Intg 
1 
r 

1 1 

} LU i 

1 t 

1 

1 Intg 
1 

1 1 

1 NAMFRM ; 

! Intg 


Code 


Math 


0 

0 

I 

I/O 

X 

I 

0 

I 

I 


Mils, 


Sgisige. 

A 

A 

A 

A 

C 

A 

A 

C 

A 


EytgrnsI,. 




Najjje or buffer 

Total number of characters stored 
in FORBOF 

File manager data control block 
File manager error flag 
Unit containing FORM file 
Length of FORBUF 

Array containing lengths of records 
stored in FOHBUF 

User terminal unit number 

Name of file containing the form 


NOTES: 


TYPE 




1 SSSi 


1 

1 

SOURCE 

Free 

DubI 

10CH 

Mix 

t 1 = 

Input 

1 

1 

XT = Interface Table 

Intg 

2CH 

36 CH 

Char 

! 0 = 

Output 

1 

1 

T = Terminal 

Real 

6CH 

72CH 

Bln 

J I/O 
1 

t 

= Input/Output 

1 

1 

1 

1 

A := Calling Argument 
C = Coomon 


F = Disk File 

SAM - System Available Memory 
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Figure 8.5.10-1.- FMING functional logic flow. 
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8.5. 11 


8.5.11.1 Purpose 

The sole purpose of LINDG Is to provide a raechanism whereby the routine LTMAG 
can be used by both DOC and LTBLO. UNDO allows LTMAG bo be used by DOC, while 
a similar routine allows LTMAG to be used by LTBID. 


6.5.11.2 Funotional Desoripblon 

The only futiotlon of LINDG is to call LTMAG, then return to DOC. There are no 
inputs, no outputs, no internal variables, and no executable logic. 


8.5.11.3 Assumptions and Limitations 
None . 

8.5.11.1J Method 
None. 

8.5.11.5 Boutine Input/Output Variables 
None, 

8.5.11.6 Funotional Logio Flow 

The functional logic flow for LINDG is presented in figure 8.5.11-1, 


8.5.11.7 Diagnostics and Debug 
None , 

8.5.11.8 Special Comments 
None, 

8.5.11.9 References 
None, 
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Figure 8.5.11-1.- LINDG functional logic flow. 
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6.5.12 ■BouUne-Niuntf,=. HajLa.JPr.w;rflm- mXPQ, 


8.5.12.1 Purpose 

The sole purpose of LNXDO Is to call subroutine LTXIG and to return to DOC. 

LTXtO ia used by both LTBLD and DOC, However, the main program of a segment 
must contain the name of the master segment that called it, Therefore, to avoid 
duplicating LTXIG with that single difference, LHXDQ was written bo oall LTXIG 
and return to DOC. A similar routine exists for LTBLD, 

There are no inputs, no outputs, no internal variables, and no program logic, 

8.5.12.2 Functional Desoripoion 
None, 

8.5.12.3 Assumptions and Limitations 
None . 

8.5.12.11 Method 
None. 

8.5.12.5 Routine Input/Output Variables 
None . 

8.5.12.6 Functional Logic Flow 

The functional logic flow for LNXDG is presented in figure 8,5.12-1. 


8.5.12.7 Diagnostics and Debug 
None . 

8.5.12.8 Special Comments 
None . 
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8.5.12,9 References 
None , 
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Figure 8.5.12-1.- LNXD6 functional logic flow. 
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8.5.13 MjmitJLnsJma 


8,5.13.1 I’urpoae 

The purpose of this routine is to display extended prompts when requested l>y the 
Liii;:age Table Editor. 

Special Note 

Tliia I’outltip ia almost Identioal to the FDS Executive routine named XTPRM. The 
funotion performed by LPRMG for the Linkage Table Editor is identioal to the 
function performed by XTPBM for the Interface Table Editor, LPRMG was developed 
by copying XTPRM and changing the name of the PROMPr file to be read. The 
modified copy was then given the name LPRMG to avoid conflict with the original. 

For this reason, LPRMG is not documented separately. Instead, the reader ia 
referred to the documentation for subroutine XTPRM in the FDS -1 Executive doou- 
mentation , 
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8.5, 1^.1 Purpose 

The purpose of this subroutine is to maintain a directory of LINKAGE TABLE 
and PROMPT files that are currently defined in the system, Each entry in 
the directory contains the file name, the six-oharaoter dooument and segment 
names, the two-character document and segment ID's, the version number, and 
a short (up to 1}8 characters) description of the contents of the file. 


8.5# 1^.2 Functional Description 

LTDIG is called either to add an entry or to delete an entry. In either 
case, the directory file is copied onto a new file, with the specified change 
being incorporated into the new file. If an entry is to be added, the present 
file is searched for the specified name. If the name is found, that entry 
is not copied to the new file. If the name is not found, the new entry is 
simply added to the new file. 

If an entry is to be deleted, all entries are copied into the new file except 
the entry to be deleted. After the new file la completed, the old file is 
purged and the new file is given the name of the old file. If an entry was 
deleted, the file corresponding to the deleted entry is also purged from the 
disk. 


8,5, 1^,3 Assumptions and Limitations 
None. 


8.5.U.»< Method 
None. 


8.5.1*t,5 Routine Input/Output Variables 

The LTDIG input/output variables are presented in table 8.5. 1^1-1. 


8, 5. 1^.6 Functional Logic Flow 

The functional logic flow for LTDIG is presented in figure 8,5. 1^-1. 


8.5, 1*1.7 Diagnostics and Debug 


None. 
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6,5,lt|,B Special Comraonbs 
None, 

neferenoQs 

None , 
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Figure 8.5.H-1.- LTDIG functional logic flow. 
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8.5.15 &M)?r,<?.UtlRe-LTIE.a 


8.5.15.1 Purpose 

The purpose of this subroutine is to write the new linkage table, whioh has been 
constructed in common, out to a disk file. 


8.5.15.2 Functional Description 

The length of the file to be created is computed, and a new disk file is 
created. If a file already exists by the same name, the old file is purged. 

The main body of the linkage table is then written to the new file. If a lit- 
eral record exists, it is then written to the file as the second record. If the 
new linkage table was created from a previous linkage table, the name of the old 
file is tested to see if it was a nondefault table that belonged to the current 
user. If it was, the user la given the opportunity to delete the old file. 


8.5.15.3 Assumptions and Limitations 
Nona. 


8,5. 15.JI Method 
None. 


8,5.15.5 Routine Input/Output Variables 

The LTIFG input/output variables are presented in table 8.5.15-1. 


8.5.15.6 Functional Logic Flow 

The functional logic flow for LTIFG is presented in figure 8,5,15-1. 


8.5.15.7 Diagnostics and Debug 
None. 

8.5.15.8 Special Comments 
None, 
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8.5.15.9 References 

Hone. 
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TABLE UiPtrr/OUTPUT VARIABLES 

Routine LTIFG 


Math 

jsypbgl- 


■ .Typs. 

Intg 

Intg 

2CH 

Intg 

Intg 

6CH 

Intg 

6CH 

Intg 

mtg 


I 

I 

I 

I 

I 

I 

I 

I 

I 

0 




c 

c 

c 

c 

c 

c 

c 

c 

c 

c 


TYPE 




1 

j 

1 

t 

sss. 


t 

1 

1 

1 

SQORCE 

Free 

Dubl 

i8ca 

Mix 

t 

1 

I = 

Input 

1 

1 

IT 2 : Interface Table 

Intg 
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Figure 8.5.15-1,- LTIFG functional logic flow. 
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8.5.16,1 Purpose 

The purpose of subroutine LTHAG is to initialize various common parameters 
and to direct the execution flow through the subroutines that actually cre- 
ate linkage tables. The oreation of linkage tables from either DDT's or 
other linkage tables is supported. 


8.5.16,2 Functional Description 

LTMAC provides two different seta of capabilities; one set is available to 
LTBLD, and the other is available to DOC, Speolfioally, if called from LTBLD, 
either a DDT or another linkage table may be used as input, a new LINKAGE 
TABLE file will be built. If called mom DOC, only a linkage table may be 
used as Input, and the user is given the option to produce a new LINKAGE 
TABLE file. LTMAG cannot call the Linkage Table Editor directly due to the 
limitation of memory size on the HP21MX, For this reason, instead of simply 
calling the editor when It is time to complete the table, control is passed 
back to the master segment, which in turn calls the editor. After the editor 
has oompleted its execution, LTMAG is called a second time to complete Its 
processing. This is aoompllshed by having the master segment (LTBLD or DOC) 
set a flag before eaoh call to LTMAG indicating which call 1s being executed. 


8.5.16.3 Assumptions and Limitations 
None , 

8.5.16.4 Method 
None . 

8.5.16.5 Routine Input/Output Variables 

The LTMAG input/output variables are presented in table 8.5.16-1. 

8.5.16.6 Functional Logic Flow 

The functional logic flow for LTMAG is presented in figure 8.5.16-1, 

8.5.16.7 Diagnostics and Debug 
None , 
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8,5.16,8 Special Comments 
Hone . 
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8,5.16.9 Referenoea 
Norm . 
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TABLE 8,5.16-1.- mPOT/OUTPDT VAHIABLES 
Routine LTMAG 
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Figure 8. S. 16-1.- LTHAG functional logic flow. 
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8. P.17 ^i>.br.o,ut^ne.,LTMO.g 


8,5.17.1 Purpose 

LTMOG Is oalled when a new linkage table is to be created iV<om an existing one. 
LTMOG initializes the common buffer with the old linkage table and various con- 
trol flags in preparation for the modifioation of the table by the Linkage Table 
Editor , 


8.5,17,2 Funotlonal Description 

A linkage table is valid only if it has the same version number as the current 
PROMPT file. Therefore, the first step in using a linkage table is to determine 
its validity by reading and comparing the version numbers from the speoifled 
LINKAGE TABLE and PROMPT files. If they agree, the linkage table (with 
literals) is read into cioramon. The short prompts are then read frcni the PROMPT 
file and placed in common with the linkage table. Control is then returned to 
LTMAG for conpletlon of the new linkage table. 


u. 5, 17.3 Assumptions and Limitations 
None . 


8.5.17.'» Method 
None. 


8,5.17.6 Routine Input/Output Variables 

The, LTMOG input/output variables are presented in table 8.5.17-1. 


8.5.17.6 Functional Logic Flow 

The functional logic flow for LTMOG is presented in figure 8.5.17-1. 

8.5.17.7 Diagnostics and Debug 
None. 
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8(5.17.0 Special Comments 
None. 

6.5.17.9 Oeferenoos 
None. 
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TABI£ 8.5. 17-1.- INPUT/OOTPDT VARIABLES 
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Figure a.5.17”1.- LTMOG functional logic flow. 
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8 . 0 . 1 8 iJj 


8,5.18.1 Purpogo 

The purpose of this subroutine is to prompt the user for the name of the linkage 
table to be used for this execution and to verify its validity by searching a di- 
rectory of valid names. A name is valid only if it exists in the directory, and 
the associated document and segment Identifiers agree with the document and seg- 
ment specified for the current execution. 


8.5.18.2 Functional Description 

The user is first prompted for the desired linkage table name. Linkage table 
names are constructed from three, parts. The first character is always an "L," 
The last character is supplied by the program and is either an asterisk or the 
single-character user ID, The middle four characters are either provided by the 
user, or, if a default name is requested, are constructed from the two-character 
document and segment ID's. 

The user may respond in the following ways to the prompt, 

Bag.pan.as Ao.tlo.n 

7 List directory 

% Abort session 

Space, carriage return Use default name (LDDSS") 

Space, user ID Use user- lefault name (LDDSSU) 

XXXX Use table named LXXXXU 

XXXXY Use table names LXXXXY 

Where DD = two-character document code 
SS = two-character segment code 
• = last character of master default name 
U = one-charaoter user ID 
XXXX = user-specified name 
Y = user ID of another user 

After the user has specified a name, the directory of existing names is searched 
for that name. If the name is not found, the user is notified and reprorapted. 

If the name is found , but the table with that name is for a different document 
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segtnenbi the user is notified and reprompted. When the name is determined to be 
valid, it is stored in common , 


8,5,18.3 Assumptions and Limitations 

LTNMG assumes that a directory name ^LTDIG exists on the HP21HX mass storage 
system, 

8,5,18.11 Method 
None . 

8.5.18.5 Routine Input/Output Variables 

The LTNMG input/output variables are presented in table 8,5.18-1. 

8.5.18.6 Functional Logic Flow 

The functional logic flow for LTNMG is presented in figure 8.5.18-1. 


8.5.18.7 Diagnostics and Debug 

PJjKHgatifl 

Unable to open linkage table directory. 

You have requested sora'jone elae’s 
default table. 

Requested linkage table not in directory. 

Requested linkage table is not for 
requested document and segment. 

Search for compatible linkage table 
name abandoned. 


AaJbifija 

Abort . 

Prompt to verify user's 
intentions . 

Reprompt . 

Re prompt. 

Abort. 


8.5.18.8 Special Comments 
None, 

8.5.18.9 References 
None, 
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TABii: 8 . 5 , 18 - 1 .- INPUT/ODTPOT VARIABLES 
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8.5. l‘J 


8.5.19.1 Purpose 

The pur pope of this subroutine is to prompt the user fbr the name of the linkage 
table to be created during this execution, and to detonnine whether or not the 
requested name already exists in the directory. If the name does not already 
exist, it is stored in common and control is returned to the calling program. If 
it does exist, the program determines wliether or not it is appropriate to recre- 
ate the table, and if that is what the user Intended. 


8.5.19.2 Functional Description 

If a DDT is being used as input, then the master default name is autoraatioally 
created. Otherwise, LTNNG must determine the name to be created. 

The user is first prompted for the desired name for the new linkage table. The 
acceptable responses and the linkage table naming conventions are the same as 
those described in LTM4G, with the exception that utilizing other user's ID's is 
not permitted. 

After the user has specified a name, the type of name requested must be 
determined . 

The creation of master default tables is only permitted from LTBLD. If LTNNG is 
called from DOC , a diagnostic is displayed and the user is reprorapted . 

If a user-default name is requested, the request is compared with the user ID 
for the session, and the request is rejected if they are different. 

Similarly, if a nondefault name Is requested, a name with another user's ID will 
be rejected. 

When a name has been supplied that satisfies the above criteria, it is stored in 
common and control is returned to the calling program. 


3.5.19.3 Assumptions and Limitations 

LTNNG assumes that a directory named $LTDIG exists on the HP21MX mass storage 
system . 


8,5. 19. Method 
None. 
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The L.TNNQ input/output variables are presented in table 8.5.19-1. 
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8,5.19.6 Functional Logic Plow 

The functional logic flow for LTNNG is presented in figure 8.5,19-1. 


0.5.19.7 Diagnostics and Debug 

Dlagn.flB.tAfl 

Master default table may not be 
recreated from DOC, 

You may not create a table 
with another user’s ID, 

Unable to open Linkage Table Directory, 


A linkage table named XXXXXX already 
exists for another document segment. 
You must select another name, 

8,5.19.0 Special Comments 
None, 


Ag.t.lOtl. 

Reprompt (occurs only if 
called from DOC) , 

Re prompt . 

Abort, 

Ask user if he wants to recreate 
this table. 

Reprompt , 


Linkage table named XXXXXX already exists. 


8.5.19.9 References 
None. 
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TABLE 8,5.19-1.- IHPUT/OUTPOT VARIABLES 
Routine . . , JiIMG 
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6.5.20.1 Purpose 

The purpose of this subroutine i,j to create the PROMPT file that Is used by the 
Linkage Table Editor. The short prompts (parameter names) and extended prompts 
(paramoter descriptions) are constructed from information contained in the DDT. 

8.5.?0.2 Fiinotional Description 

Upon entry into LTPFQ, the name of the current linkage table is tixtraoted fY'om 
the linkage table header record. The first character of the name is changed to 
a "P" Co indiorte PROMPT file. A new disk file is then created using the prompt 
file name . 

The short prompts are written directly from the linkage table buffer into the 
first two records of the PROMPT file. The extended prompt records are produced 
by reading eaoh entry from the DDT, and then writing that entry onto the PROMPT 
file, one entry per record. 

6.5.20.3 Assumptions and Limitations 
None. 

8.5.20.4 Method 
None, 

8.5.20.5 Routine Input/Output Variables 

The LTPFG ir.put/output variables are presented in table 8,5.20-1. 

8.5.20.6 Functional Logic Flow 

The functional logic flow for LTPFG is presented in figure 8.5.20-1. 

8.5.20.7 Diagnostics and Debug 
None. 
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8^5.20.8 Special Comments 
None , 

8,5.20,9 References 
None , 
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Figure 8.5.20-1.- LTPFG functional logic f ■ 


V ■ of 1 


8-99 





77FM18:V 


B. 5 . 


8.5.21.1 Purpose 

The purpose of this routine is to manage the creation of a new linkage table 
frcBi the information contained in the DDT. The linkage table, with short 
prompts, is constructed in common in exactly the same format as an Interface 
table. This permits the use of the unmodified Interface Table Editor as the edi- 
tor for the linkage tables. 


8,5.21.2 Functional Description 

LTPRG first extracts data from the header record of the DDT and constructs the 
header of the linkage table, header contains the number of parameters, the 

version number, the linkage table name, and the document segment and user codes 
assOoiated with this table. The number of parameters is then used to determine 
the number of records to be read from the DDT. As each record is read, the 
required information is stored in common for that parameter. This information 
is the short prompt, class, type, dimension, and size. 


8.5.21.3 Assumptions and Limitations 
None, 

8.5.21.4 Method 
None, 

0.5,21.5 Routine Input/Output Variables 

The LTPRG input/output variables are presented in table 8,5.21-1. 

8.5.21.6 Functional Logic Flow 

The functional logic flow for LTPRG is presented in figure 8,5.21-1, 

8.5.21.7 Diagnostics and Debug 
None . 
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8.5i,21.8 Speoi il Comments 
None , 
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3.5.21.9 Rcferencea 
None. 
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TABI£ 3.5.21-1.- INPUT/OllTpDT VARIABLES 
Routine LTPRG 


Code 

1 1 

i Hath 1 

_ i gy^DboI j 
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1 t 

1 t 
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Figure 8.5.21-1.- LTPRG functional logic flow. 
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8.5.22 


8.5.22.1 Purpose 

The purpose of LTXIQ is to initialize all of the various flags that are used by 
the Linkage Table Editor, and to call XINIX, which is the entry routine into the 
editor. If LTXIG is called from DOC, then it will refuse to exit until the link- 
age table is ccmplete. 


8.5,22.2 Functional Description 

The Linkage Table Editor is initialized by setting a aeries of control flags in 
common. If there are any lltr:rals in the literal array, subroutine XEINT is 
called to unpack them into a usable format. Subroutine XINIX is then called to 
access the editor. If LTXIG was called from LTBLD, control is returned to the 
calling program at this point. If it has been called from DOC, the linkage 
table is tested for completeness. If it is incomplete, a message is sent to the 
user, and XINIX is called again. This process is repeated, if necessary, until 
the table is complete. 


8.5.22.3 Assumptions and Limitations 
None. 


8. 5.22. H Method 
None , 


8.5,22.5 Routine Input/Output Variables 

The LTXIG input/output variables are presented in table 8.5.22"I, 


8.5.22.6 Functional Logic Flow 

The functional logic flow for LTXIG is presented in figure 8.5.22-1. 

8.5.22.7 Diagnostics and Debug 
None. 
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8.5.22.8 Special Comments 
None, 

8.5.22.9 References 
Hone , 
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TABLE INPUT/OOTPUT VARIABUBS 

Routine _ LTXIG_ _ 


Code 
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t 1 

Intg 
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1 t 
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TABLE 8*5*22-1-- Concluded 
Boutin e . 
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6.5.2'^,1 Purpose 

The purpose of MBRO is to merge the reformatted data Into the reserved blank 
3paoes in the form. HBRG will continue to perform this function until the laot 
h nnk space in the buffer has been used, When this happens, the completed por- 
I'on of the segment is paged out to the OUTPUT file, and the next buffer of 
blnnk forms is paged into memory. The merging Amotion is then resumed, 


8, ‘*^..'*3.^ Functional Description 

In general, a complete blank form will be larger than the available Internal 
buffer space. For this reason, the form is paged into memory in portions that 
will fit in the buffer. The form is read in line-by-line. Because a blank data 
field cannot extend fron one line to the next, there will never be a left 
bracket in the buffer that is not accompanied by a right bracket, 

MBRG is called for each data value that has been retrieved and reformatted by 
DOPRQ. MERG searches the FORBUP array for the next left bracket. The data 
value is placed in the FORBUF array, beginning with the character position 
occupied by the left bracket, and continues through the position occupied by the 
right bracket. If the data value la too long, it is truncated. If it is too 
short, the remaining spaces in the form are filled with blanks. 

If the end-of-data flag is encountered without finding a left bracket, sub- 
routine SOUTG is called to write the completed portion out to the OUTPUT file. 
Subroutine FMING is then called to bring the next portion of the blank form into 
the buffer so that processing can be continued . 


8.5.23.3 Assumptions and Limitations 
Hone. 

8.5.23.4 Method 
None . 

6.5.23.5 Routine Input/Output Variables 

The MEHG Input/output variables are presented in table 8,5.23-1. 


8.5.23.6 Functional Logic Flow 

The functional logic flow for MERG is presented in figure 8.5.23-1, 
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8,5.33.7 OingTOcblOB and Debug 
None , 
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8.5.23.8 Special Comments 
None. 

0,5.23.9 Heferences 
None . 
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TABLE 8.5.23-1.- INPUT/OUTPOT VAHIAELES 
Routine . . HEBG 
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Figure 8*5.23-1,- MERG functional logic flow. 
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8.5.21) 


8.5.21). 1 PiH'poae 

Tlj© pvirjxinc of this subroutino is to rond eiblior the blank form op the merged 
aopnent fran the disk, and display it at the user* a tominnl (or an optional 
hnrd-oppy device) . 


8.5.2)). 2 Functional Cesoriptlon 

The file to be displayed is indioated by the input variable lOPTN. For 
lOPTN s 1, the merged segment is to ba displayed, For lOPTN = 0, the blank 
form is to be displayed. 

Immediately upon entry, SDISG prompts th< user to find out if a display is 
wnntod. If not, control is returned to the calling program. If a display is 
requested, the user is then prompted fop the optional hard-oopy unit number. A 
null response (space, oarriago return) will suppress the hard copy. 

If a display is requested, the specified file is read and displayed line-by-line. 
If the display is being sent to one of the HP21MX terminals, it is blocked 
into 22-line pages to faollitate reading by the user. 

After each page, the user is prompted with a "CONTINUE?" to ere' im to re- 
quest the next page. If the display is going to a non-HP2’,^^X “ it is 

sent in its entirety without paging , 


8.5.2^t.3 Assumptions and Limitations 
None . 

8,5.2)).)) Method 
None . 

8.5.24.5 noutlna Input/Oubput Variables 

The SDISG input/output variables are presented in table 8.5.2))-I. 


8.5,24.6 Functional Logic Flow 

The funotlonal logic flow for SDISG is presented in figure 8.5.24-1, 
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0,5.24.7 Diafr.iostios and Debug 
>Jone , 
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0.5.24,0 SpGOlal Commenta 
None, 

8,5.24.9 nufe<’etio(jJ 
None, 
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TA.Et£ e. 5 . 2 ‘i-I.~ IHPDT/OCTPUT VAHIAELES 
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Figure 8.5.24-1,- SDISG functional logic flow. 
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8 . 5 . 2 ^> 


8,!3.25.1 Purpose 

The purpose of SOUTG is to page the merged portion of a doouraent segment out to 
the OUTPUT file. Since segments may be larger than the available internal 
buffer spaoe, it is necessary to read, process, and store the segments in 
smaller portions, called pages. These pages are aoouniulated in an OUTPUT file 
until the entire segment has been processed, The segment is then ready to be 
sent to the Daconlos . 


8.5.25.2 Functional Desorlption 

First the OUTPUT file is opened, and the file is positioned to the next record 
to bo written. The page is written out to the file by determining the number of 
oharaoters in each record, packing than into an A2 format, and writing to the 
file. As eaoh record is written, the record counter is inoreraentod so that the 
file can be positioned to the correct record for the next page, 

8.5.25.3 Assumptions and Limitations 
None , 

8.5.25.11 Method 
None , 

8,5.25.5 Routine Input/Output Variables 

The SOUTG Input/output variables are listed in table 8.5.25-I. 


8.5.25.6 Functional Logic Flow 

The functional logic flow for SOUTG is presented in figure 8,5.25-1. 

8 . 5 . 25.7 Diagnostios and Debug 
None . 
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fl.5.25.8 Sptjoial Comments 
None. 
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8.5.25.9 References 
None. 


8-118 



8-119 


77FH1S: 


TABLE 3.5-25-1.- IHPUT/OOTPUT VARIABLES 
Routine SOUTG 
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Figure 8.5.25-1.- SOUTG functional logic flow. 
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